Oort Knowledge Base
  • Home
  • Glossary
  • 📊Dashboard
    • Get Started Dashboard
    • Overview Dashboard
    • MFA Dashboard
  • 👥Understanding your users
    • 📇Users
      • 💾Saved Filters
      • ❓Basic Search & Advanced Query Mode
    • 🩻User 360
      • 🗺️Overview Tab
      • 🔬Activity Tab
      • 📶Networks Tab
      • 💻Devices Tab
      • 🪺Applications and Groups Tabs
      • ✅Checks Tab
    • 🛠️Triaging Alerts and Remediation Actions
    • 🔗Linking User Accounts
    • 🤷User Statuses
  • 🗃️Applications
  • 💻Devices
  • 🧩Configuring Integrations
    • Managed Integrations
    • Auth0
      • Auth0 Data Integration
      • Auth0 Log Streaming & Marketplace App
    • Microsoft Entra ID (Azure AD) Data Integration
    • Microsoft Entra ID (Azure AD) SSO Integration
    • Azure Event Hub Log Streaming for Microsoft Entra ID (Azure AD)
    • Azure Sentinel SIEM Integration
    • AWS
    • AWS User-Based Access [Deprecated]
    • Duo Security Integration
    • Email Notifications
    • Github
    • Google Workspace Integration
    • Jamf
    • Jira Integration
    • Mailgun Integration
    • Microsoft Teams Notification Integration
    • Okta Log Streaming AWS EventBridge Integration
    • Okta Data Integration
    • Okta Workflows
    • Okta Integration Network - Production SSO App
    • Okta SSO
    • Polarity Integration
    • Salesforce Integration
    • SendGrid Integration
    • ServiceNOW Integration
    • Slack
    • Snowflake
    • Webex Notification Integration
    • Webhooks
    • Workday
      • Manual Import (CSV)
      • Report as a Service (RaaS)
  • ☑️Understanding Check failures
    • 🔍Reviewing Check Results
    • 🧹Customizing Checks
    • 📖Cisco Identity Insights
      • Identity Posture Management Insights
        • Access from Denied Territories
        • Allow/Block Email Logins
        • Application Login Bypasses SSO
        • Applications with Expired Secret
        • HRIS Discrepancies
        • Identity Intelligence Client Secret Expiring Soon
        • Inactive Account Probing
        • Inactive Guest Users
        • Inactive Users
        • Missing Value in Mandatory Field
        • Never Logged In
        • No MFA Configured
        • No Strong MFA Configured
        • Okta Long Running Sessions
        • Okta Session Length Policy Compliance
        • Personal VPN Usage
        • Provider User Type Missing
        • Rate Limit Alert
        • Role Assigned to Azure Cloud Only Account
        • Salesforce Direct Login Settings
        • Shared Mailbox Sign In Enabled
        • Slack User Inconsistencies
        • Telecom MFA Limit Reached
        • Unmanaged Devices Access
        • Unused Application for a User
        • Upcoming App Key Expiration
        • User Authorized to Bypass MFA
        • User Has Directly Assigned Application
        • User in IDP but not in HRIS
        • User Password Expiration Failure
        • User Stuck in Non-functional State
        • Users Sharing Authenticators
        • Weak MFA Was Used To Successfully Sign In
      • Identity Threat Detection Insights
        • A Bypass Code Was Used To Successfully Sign In
        • Access From Dormant Account
        • Accounts With Unusually High Activity
        • Active Account Under Heavy Attack
        • Activity From Untrustworthy ISP
        • Admin Impersonation in Okta
        • Admin Role Assigned to User
        • Authenticator Registration Anomalies
        • Code Exfiltration By Guest Account
        • Compromised Session
        • Google Drive File with Excessive Sharing Permissions
        • Impossible Travel
        • IP Threat Detected
          • IP Threat Detected In Depth
        • Login to Admin Console
        • MFA Flood
        • Microsoft Entra ID Admin Activity Anomaly
        • New Country for Tenant
        • New IDP Created
        • Okta Admin Activity Anomaly
        • Rare Browser Activity
        • Registered Location Mismatch
        • Risky Parallel Sessions
        • Service Account Successful Sign In
        • Shared Mailbox Successful Sign In
        • Sign In Threat Detected
        • Sign-in from Recently Created IdP
        • Successful Access from a Previously Only Failing IP
        • Super Admin Login to Google
        • Suspicious Activity Reported by End User
        • Unusual Repo Access
        • User IP in Blocked State
        • User Lock Out Risk Detected
        • User Trust Level Alert
        • Users With Defined Email Forward Rules
        • Users With New Email Forward Rules
        • Weak MFA Manually Activated and Utilized
  • ⚙️Tenant Settings
    • 👨‍💼Role-based Access (RBAC) and Tenant Access Logs
    • Systems Logs
  • 🏥Identity Posture Score
  • 🚨User Trust Level
  • How-to Guides
    • 🔐Accessing and Securing your Cisco Identity Intelligence Tenant
    • 🏎️Can Identity Intelligence analyze behavior and fail checks more frequently?
    • 🛂Importing Known IP Address Lists
    • 🔎Networks Tab & User Investigations
    • 🔁Okta Workflows Webhook Example
    • 🗃️Understanding HRIS Data and SCIM
    • MFA Factors FAQ
  • Public API
    • APIs
  • Troubleshooting & Support
    • API Permissions for Integrations
    • Responsible Disclosure Policy
  • Best Practices
    • 🛣️What’s Next? How to use Identity Intelligence effectively
    • 📚Identity Security Reading List
    • ✍️KPIs for
 IAM Teams
  • Blogs
    • 0ktapus for humans
    • Oort Releases GitHub Integration To Extend Identity Threat Detection
    • Oort Recognized Twice as a Sample Vendor in Gartner® 2023 Hype Cycle Reports™
    • Oort's Response Capabilities: Remediate Compromised Accounts with Just One Click
    • Oort Unveils Dashboard, Providing A Single Pane of Glass for Identities
    • Oort’s New Identity Security Dashboard
    • Oort Unveils Identity Technology Ecosystem, Bringing Identity Data out of Orbit and Into View
    • Oort: Your Security Layer On Top Of Okta
    • Populating the Unpopulated: Challenges of Building a Comprehensive User Inventory
    • Protecting IT Help Desk Teams Against Cyber Attacks
    • Protecting Salesforce Accounts from Takeovers and Ungoverned Access
    • Restrict Guest Access Permissions: Best Practices and Challenges
    • Seizing the Communication Opportunity: Aligning Perspectives in Identity Security
    • Session Hijacking in a Post-Genesis World
    • SIEM vs. Security Data Lake: Why it's Time to Rethink Your Security Program
    • Speaking the Same Language for Identity Security: Identify, Protect, Detect, Respond
    • State of Identity Security research reveals 40% of accounts use weak or no form of multi-factor authentication to protect identities
    • Strengthening Identity Controls: Mapping to CIS CSC and NIST CSF Security Frameworks
    • Strengthening Identity Security with Single Sign-On (SSO) Systems
    • Succeeding with Proper Detection for Identity Security: A Comprehensive Approach
    • Taking a Data-Driven Approach to Identity Security
    • The Concerning Prevalence of Weak Second Factors
    • The Crucial Role of an Identity Security Leader
    • Why I am Joining Oort
    • The Quest for a Passwordless World
    • Understanding Azure Active Directory (Azure AD)
    • Understanding the Implications of New SEC Rules on Cyber Incident Disclosure
    • Unlocking the Power of Zero Trust: The Crucial Role of Identity and Oort's Identity Security Platform
    • Respond Even Quicker to Identity Threats
    • What to Look Out For at Gartner IAM
    • 7 Critical Requirements for Securing Third-Party and Vendor Access
    • Best Practices for Efficiently Responding to Identity Threats
    • Announcing our Identity Technology Partner Ecosystem
    • Catching waves and building clouds
    • Cisco Announces Intent to Acquire Oort
    • CISO Perspectives: Eric Richard, HubSpot
    • Defining Roles & Responsibilities for an Identity Security Program
    • Detecting Session Hijacking
    • 8 Things to Look for in an ITDR Solution
    • Enhancing Identity Threat Detection: Introducing Oort’s New GitHub Integration
    • Founder Perspective: Matt Caulfield On Why He Started Oort
    • Founder Perspective: Vision To Reality
    • Four Reasons Why Traditional SIEMs Fall Short For Identity Security Programs
    • How Oort Partners with Duo for Unbeatable Secure Access
    • Governance, Risk, and Compliance
    • How to Find Inactive Users
    • Identity and Access Management and Oort Explained
    • 5 Identity Security Questions Every IAM Leader Needs to Answer
    • Identity security is bigger than just ITDR
    • Identity is the apex threat vector, so why is identity security still a mess?
    • Identity Threat Detection
    • Identity Threat Detection and Response: what you need to know
    • Identiverse 2023: What I'm Looking Forward to & What Not to Miss
    • Interview with Oort: Best Practices for Managing & Protecting Service Accounts
    • Interview with Alex “Sasha” Zaslavsky (Oort Data Science Lead)
    • Interview with Andy Winiarski (Head of Solutions Engineering)
    • Interview with Nicolas Dard (Oort’s VP of Product Management)
    • Introducing our Latest Integration to Protect Identities in AWS
    • Introducing The 2023 State of Identity Security Report
    • Maintaining a Strong Identity Security Posture: Why IAM Hygiene Matters
    • Managing Machine Identities: A Comprehensive Guide
    • Managing Risk In Shipwreck Diving and Security
    • Monitoring MFA Usage and Adoption: Strengthening Your Security Strategy
    • Okta Breach: Why Attackers Target GitHub, and What You Can Do to Secure It
    • Okta Security
    • Oort and Polarity Combine to Provide Instant Context on Identities
    • Oort + Polarity: Instant Identity Context to Power Investigations and Response
    • Oort Announces $15M in Seed and Series A Funding Round
    • Oort Stacks Go-to-Market Leadership Team Following Series A Investment
    • Oort Extends Identity Threat Detection with New AWS Integration
    • Announcing General Availability of the Oort Identity Analytics & Automation Platform
    • Oort Joins Forces with Microsoft Intelligent Security Association to Bring Visibility into Unmanaged Devices
    • Oort Joins the Microsoft Intelligent Security Association (MISA)
    • Building an Effective Identity Security Program: A Comprehensive Handbook
    • Oort Launches Identity Security Platform in Auth0 Marketplace
    • Oort Launches Identity Security Platform in AWS Marketplace
    • Oort Launches One-Click Remediation Actions for Streamlined Identity Security Response
    • Oort Origins and Our Vision for Identity Security
  • Release Notes
    • Week 22, 2024
    • Week 21, 2024
    • Week 20, 2024
    • Week 19, 2024
    • Week 18, 2024
    • Week 17, 2024
    • Week 16, 2024
    • Week 14, 2024
    • Week 13, 2024
    • Week 11, 2024
    • Week 9, 2024
    • Week 7, 2024
    • Week 5, 2024
    • Week 4, 2024
    • Week 3, 2024
    • Week 2, 2024
    • 2023
      • Week 49, 2023
      • Week 48, 2023
      • Week 47, 2023
      • Week 46, 2023
      • Week 45, 2023
      • Week 44, 2023
      • Week 43, 2023
      • Week 42, 2023
      • Week 41, 2023
      • Week 40, 2023
      • Week 39, 2023
      • Week 38, 2023
      • Week 37, 2023
      • Week 35, 2023
      • Week 34, 2023
      • Week 33, 2023
      • Week 32, 2023
      • Week 31, 2023
      • Week 30, 2023
      • Week 29, 2023
      • Week 28, 2023
      • Week 27, 2023
      • Week 26, 2023
      • Week 25, 2023
      • Week 24, 2023
      • Week 23, 2023
      • Week 22, 2023
      • Week 21, 2023
      • Week 20, 2023
      • Week 19, 2023
      • Week 18, 2023
      • Week 17, 2023
      • Week 16, 2023
      • Week 15, 2023
      • Week 13, 2023
      • Week 12, 2023
      • Week 11, 2023
      • Week 10, 2023
      • Week 9, 2023
      • Week 8, 2023
      • Week 7, 2023
      • Week 6, 2023
      • Week 5, 2023
      • Week 4, 2023
      • Week 3, 2023
      • Week 2, 2023
      • Week 1, 2023
    • 2022
      • Week 51, 2022
      • Week 50, 2022
      • Week 49, 2022
      • Week 48, 2022
      • Week 47, 2022
      • Week 46, 2022
      • Week 43, 2022
      • Week 42, 2022
      • Week 41, 2022
      • Week 38, 2022
      • Week 37, 2022
      • Week 36, 2022
      • Week 35, 2022
      • Week 34, 2022
      • Week 33, 2022
      • Week 32, 2022
      • Week 31, 2022
      • Week 30, 2022
      • Week 29, 2022
      • Week 24, 2022
      • Week 12, 2022
Powered by GitBook
On this page
  • Overview
  • Dashboard widgets
  • Calculation of Trust Level
  • How User Trust Level is calculated
  • Where to find User Trust Level information within Identity Intelligence

User Trust Level

PreviousIdentity Posture ScoreNextHow-to Guides

Last updated 6 months ago

Overview

Whether you have hundreds or thousands or tens of thousands of users in your environment, it can be challenging to identify which users currently pose the most risk to your organization. Finding that needle in a haystack out of all the other users in your environment who also (intentionally or not) engage in risky behavior or have identity attacks flying at them, is not only time consuming but also time sensitive. If an account has been compromised, you need to be sure that account is identified as quickly as possible so the necessary remediation steps can happen to stop the attacker from causing further damage. Because Cisco Identity Intelligence contains so much rich context and data about your users, across multiple identity sources, there are countless data points that we can use to more accurately identify and rate these risky users than other identity security tools can. Which is why we developed the concept of User Trust Levels. The User Trust Level is calculated for each user in your organization, based on the user's context, behavior and common tendencies, to help you focus on the most important threats. Trust Levels allow you to quickly and easily pick the riskiest users out of the crowd, so that you can investigate with urgency and remediate the situation as quickly as possible, reducing the attack timeframe or even preventing an attack from happening in the first place.

There are no settings related to User Trust Level and it cannot be customized directly. To learn more about tuning checks, which can impact the users failing a check and thus indirectly the User Trust Levels, please refer to our documentation on customizing checks.

Dashboard widgets

Calculation of Trust Level

Cisco Identity Intelligence weighs several factors together in a proprietary algorithm to produce a User Trust Level for each user in your organization, which ranges from Untrusted to Trusted:

  • Trusted indicates the user has an exceptional level of safety

  • Favorable indicates the user has a level of safety

  • Neutral indicates the user has been evaluated and has neither positive or negative behavior

  • Questionable indicates the user is displaying behavior that may indicate risk or may be undesirable

  • Untrusted indicates the user is displaying behavior that is exceptionally bad, malicious or undesirable

Users can also have a Unknown Trust Level which indicates the user was not previously evaluated, or is lacking features to assert a trust level.

Types of User Risk

Users and their accounts are complicated. User risk is not a monolithic concept and it is important to first understand the different types of risk to understand how a user's Trust Level is calculated. Identity Intelligence breaks down the different components that make up user risk to calculate a single User Trust Level that aggregates all the risk types:

Risk Type
Definition
Example

Inherent

The risk/impact of a user's account being taken over assuming no controls are added to the system to reduce the risk

How likely is it that this account will be targeted? (Admins, Execs, etc)

Posture

The risk of an account takeover given the posture of the account

How easy is it to take over this account? (MFA configured, password strength, factor strength, etc)

Behavioral

The risk/likelihood of account takeover based on deviations from the user's normal behavior

How likely is it that their account is compromised already? (recent behaviors, unusual activity)

Action

The risk of account takeover given the specific event and action a user is trying to take at a point in time

How likely is it that this action is legitimate? (IP, location, device, factors, apps, etc)

How User Trust Level is calculated

Identity Intelligence takes inputs from all 4 types of risks listed above to calculate the User Trust Level. The User Trust Level will be calculated based on the data available for the users in your organization's tenant. The more data available from different integration instances, the more accurate the Trust Level will be. Some of factors used in this algorithm include the following:

  • User Context:

    • Priority Users: Just like with the Identity Posture Score, Priority Users impact the calculation of the user's Trust Level differently because these accounts carry higher risk and are more sensitive than other users in your organization. Priority users are those listed as Integration Instance Admins and/or those who have Executive level titles (ex: Chiefs, President, VPs, etc)

    • Account activity: If a user's account was recently created, this impacts the calculation of the user's Trust Level differently than other users in your organization

  • User's postural habits: If a user has poor posture, they are more likely to be successfully compromised if their account were to be targeted. Identity Intelligence uses a variety of methods to determine the user's hygiene such as factor enrollment and usage, device ownership, browser usage, etc.

  • User's event behavior: Looks at the user's typical behavior to determine a baseline so that anomalous or rare events impact the Trust Level. Identity Intelligences looks at things such as IP and networks usage patterns, device patterns, app access patterns, multi-factor patterns and much more to determine events that may be higher risk. Some of this data can come from failing checks.

A single user can generate many events each day. The Trust Level calculation generates a level for each event, and then uses the maximum final level for all events in the given time period, not the average or the sum.

Other factors in your Identity Intelligence tenant can also impact User Trust Levels such as:

  • Disabled checks: Checks that are included as part of the User Trust Level calculation but have been disabled in your organization are not used in the Trust Level Calculation. For the most accurate User Trust Levels, ensure that all checks are enabled in your tenant

  • Check configuration settings: Identity Intelligence analyzes various check failures as part of the User Trust Level calculation. You may find that certain checks are too lenient or too strict and need to be customized to better align with your organization's risk tolerance thresholds

Cisco Identity Intelligence is continuously refining its Trust Level algorithm to include new factors, and modifying the weighting of factors, to provide the most up-to-date and accurate portrayal of user trust as possible. Any updates to the calculation will be reflected on this page

Where to find User Trust Level information within Identity Intelligence

Throughout Identity Intelligence there are a few places where you can see User Trust Level information with different degrees of detail:

  • Check Failure Explainability and Notifications - shows a given failing user's current Trust Level, regardless of relation to the given check failure, to act as additional context for check failure investigations

User 360 Trust Level widget

Once you have identified a user with a trust level that you want to investigate, click that user's name to open the User360. The User Trust Level widget displayed at the top the Overview tab of the User 360 (screenshot below) shows the most detail and context about a given user's trust level. It is a great starting off point for an investigation.

The Trust Level widget will show you the User's current Trust Level and if available, what the previous Trust Level was and when the Trust Level changed from the previous level to the current level. You may not see the previous level and the date the level changed for all users in cases where this is the first time a Trust Level was calculated for the particular user, or if the previous trust level wasn't different than the current level.

Below this you will information about why the given user received this Trust Level including:

  • Summary - High level description of what happened with the given account to trigger the current Trust Level (ex: Priority account signed in from new IP address, new ISP, etc etc)

  • Additional details - Information related to the events described in the Summary, such as IPs, App Names, Device info, etc and any relevant checks failures triggered by the given account

  • Contributing events - The events that contributed to the user's current Trust Level.

    • To see a summary of the actual events, use the v arrow next to the title to expand this part of the widget. You will see up to 5 events in this view by default. You can see the other events by using the arrows at the bottom of the widget, or you can add more rows to the initial view using the Rows per page button

    • Click anywhere in a given event row, or click the View Event Details button, to open a side panel with the detailed event attributes for the selected event

  • Last Updated - the last date and time that data was collected and calculations were run to determine if there has been a change to the given user's trust level

See for high level information on how the Trust Level is determined. You can see more information about the Trust Levels of the users across your organization, as well as Trust Level trends over time, on your .

To read more about the Trust Level widgets on the Dashboard, please see our docs for detailed information about the visualizations and exportability of the data.

Integration Instance configuration: The more integration instances that are connected in your tenant, the more data that is available to contribute to the User Trust Level calculation. The more data available, the more accurate a user's Trust Level will be since Identity Intelligence can establish stronger user baselines across systems, analyze more event data points as part of the calculation and compare events across systems to reduce false flags. For this reason it is important to set up all available integration instances that exist for your environment. To learn more about what data integrations are available and how to configure them, refer to our documentation on

Sensitive Apps configuration: User Trust Levels weighs sensitive apps differently than regular apps. You may need to modify the list of sensitive apps in Identity Intelligence to align with your organization's list. Identity Intelligence has a pre-configured list of sensitive apps that can be modified via under the Tenant Settings menu item

Note: Once you add one Sensitive App to the list, it will erase the entire Identity Intelligence default list. If you want like to keep any of the default apps, be sure take a screenshot of the widget on the Dashboard before making any changes

To configure a check's settings, navigate to the check you'd like to modify. If are available for that particular check, it will be located in the top right corner of the Check page, and select Custom Detection Settings. Note that not all checks have settings that can be modified

widgets - displays aggregated User Trust Level data across your organization. Useful to quickly find users with Trust Levels you want to investigate

page - displays the current trust level per user and can be used as a filter. Useful to quickly find users with Trust Levels you want to investigate

- shows a given user's current Trust Level and context about why the user has that trust level. Read more about this below

Click the See in Context button, which is directly above the event table, to navigate to the given user's tab, pre-filtered to display all the events that contributed to the user's current trust level, surrounded by the context of the events that happened in the 48 hours before and after the user's trust level changed

🚨
Configuring Integrations
Sensitive Apps
Sensitive App Usage
Check Settings
Users
Activity
Calculation of User Trust Level
User 360 Overview tab
Dashboard
Dashboard
Dashboard