Why risk scoring is essential
In the past decade, migration to the cloud and the rise of machine identities have upended the identity security world. The number of identities organizations need to manage has exploded, both in terms of numbers and in the variety of tools and systems they inhabit. The tools and processes of the previous decade, like quarterly access reviews, are no longer sufficient. If there are 20000 identities in your organization, it’s no longer realistic to examine each in turn, A-Z, giving each equal time and consideration. This leaves identity security in an awkward transitional phase, with yesterday’s tools and processes obviously inadequate, and tomorrow’s solutions – leveraging machine learning, AI, and process automation to cope with the scale of identity – still being developed.
This means that a critical competency for any security or governance team is the ability to triage. That is, to identify, and focus on, their biggest risks in order to get maximum effect from their time and effort. Risk scoring of identities gives you the context you need to develop this competency.
Two dimensions of risk: likelihood and impact
When we talk about risk, we’re really talking about two separate concepts: likelihood, and impact. Likelihood asks “What is the chance of a particular event, like a successful phishing attack or other unauthorized access, happening within a given timeframe?”.
Impact asks “If this event happens, what is the impact on the organization, or how bad will it be? For example, will customer data be exposed? Will our core infrastructure be at risk?” Properly understanding risk requires thinking about both concepts.
Three risk factors for identity
In terms of identity security, the information we need to consider to determine risk falls under three categories: configuration, activity, and access.
Configuration
Configuration refers to how the identity is set up and how that can affect the likelihood that it may be compromised. Examples of configuration risk factors include the strength of credentials, like passwords, whether multi-factor authentication (MFA) is enabled, or for a machine identity, how often credentials are rotated. Human factors can also be considered in this category, for example, failure to complete required security training.
Activity
Activity refers to recent actions the identity has taken. Certain activity can indicate that an identity either has been or is likely to become compromised. For example, an identity authenticating from a device, IP address or geographic location where it isn’t usually seen is a strong indication that it is being used by an attacker, even if the credentials are valid.
Another example of activity-based risk is a dormant identity. Dormant entities are the primary targets fo attackers. An identity that is not being used misses out on key security updates, is less likely to have an updated or rotated password, and represents an unnecessary expansion of the identity attack surface. Moreover, if an attacker uses an identity actively in-use by a human user, then that abnormal usage can be noticed by the human user. There is no such danger for the attacker in using a dormant identity as no one will notice its abnormal usage.
Access
Access refers to the permissions an identity has. Can the identity read sensitive customer data like social security numbers or other personally identifying information (PII)? Can it delete source code? Can it manage cloud infrastructure? Beyond the direct access an identity has, we also need to consider its potential for lateral movement or privilege escalation. In other words, can the identity grant itself additional access.
Putting it all together
Going back to our two dimensions of risk, we can see that configuration and activity factors fall largely on the “likelihood” side. They tell us if an identity is in danger of being compromised. However, to calculate impact, you must understand access. Access is what tells us the consequences of a breached identity.
Access is also the area where other “threat detection and response” tools fall short. ITDR tools are strong at tracking suspicious activity and known misconfigurations, but they simply don’t have access to the authorization metadata needed to determine the real access that an identity has. This makes their conception of risk incomplete, telling you a lot about likelihood, but not enough about impact.
Veza brings access visibility to risk scoring
Veza’s Access Graph tracks the relationships of human and non-human identities—through groups, roles, and policies—to specific permissions in apps, data systems and infrastructure.
In addition to access, Veza is able to:
- Surface identity misconfigurations, like unrotated credentials or disabled MFA
- Track activity to find dormant or unused identities groups and roles
- Integrate with ITDR services like Crowdstrike Falcon to capture activity-based risk scores
This makes Veza the missing link in building a complete picture of identity risk, taking into account all three major risk factors, spanning both the likelihood and the impact of a compromised identity.
How risk scores work in Veza
Any saved query in Veza can be assigned a risk level. This includes the many built-in queries available out-of-the-box when you integrate your identity systems, SaaS apps, and infrastructure into Veza’s Access Platform. Veza assigns identities a risk score based on each query with a risk level assigned that returns that identity.
While out-of-the-box queries are assigned an initial risk value, you can always update the risk label. You can also assign risk labels to any custom query. For example, you can
Veza first assigns a base score, derived from the highest risk level an identity has. For example, an identity with at least one critical risk has a base risk score of 90. From there, scores are incremented based on the number of risks they have.
| Risk level | Base score | Increment per additional risk |
| Critical | 90 | 4 |
| High | 75 | +3 |
| Medium | 50 | +2 |
| Low | 25 | +1 |
| None | 0 | NA |
Examples:
- Identity A has 1 critical risk, 2 medium risks, and 1 low risk:
- 90 – base score for critical as the highest risk score present
- +4 – incrementer for 1critical risk
- +4 – incrementer for 2 medium risks at 2 points each
- +1 – incrementer for 1 low risks
- Total risk score = 99
- Identity B has 6 medium risks and 3 low risks:
- 50 – base score for medium as the highest risk level present
- +12 – incrementer for 6 medium risks at 2 points each
- +3 – incrementer for 3 low risks at 1 point each
- Total risk score of 65
How to use risk scores in Veza
Risks and risk scores are designed to help you tackle the immense scale of identity security by triaging identity and access issues in your organization. To this end, you can incorporate risk scores into most activities in Veza.
Access Reviews
Create and assign on-demand access reviews specifically for your highest-risk identities, to give extra consideration to potential excess privilege or misconfigurations for these identities. Reviews for high risk identities can be conducted at an increased cadence compared to lower risk identities.
In addition, risk scores are surfaced in all access reviews and give reviewers extra context in making their decision. For example, a high score might prompt a reviewer to deny access to sensitive resources.
Prioritize remediation
Risk scores are always visible in the query builder and can be overlayed on top of any other query. For example, you can filter a query showing users without active MFA to include only users with a risk score of above 90. This way, you can prioritize fixing misconfigurations for users you know are high risk.
Similarly, the results of any query can be sorted by risk score. If you’re looking at a query showing access to a sensitive resource, like customer data or source code, you can easily see if any of the identities with access are high risk.
You can also easily look at all critical risks, and rank them by the number of identities affected, so your security teams can fix org-level risks with the highest impact first.
Role substitution
While this blog focuses primarily on identities, there are other entities that confer access, such as IAM roles. In Veza, these entitites are also assigned risk scores. Visibility into risk scores for roles help give IAM teams the visiblity they need to help reduce their access footprint, through role substitutions: identifying identities that can assume high-risk roles and, where possible, replacing the assignment with a lower-risk role that still provides the access that is actually needed.
Access is fundamental to risk
To effectively assess risk, you need to know not just how likely an identity is to be compromised, but also the impact a compromise would have on your organization. To know this, you must know the access the identity has. With it’s unique visibility into both likelihood and impact of a compromise for each identity, Veza lets you develop comprehensive risk scoring for your identities, so that your IAM and security teams can focus their efforts on your biggest risks.
