Incydr's trusted activity model
Overview
Incydr uses a trust-based model to filter expected, approved file activity from unexpected, possibly risky activity. This model allows you to better identify file exfiltration, more quickly investigate events, and rapidly respond and resolve issues before they pose a threat to your intellectual property, business development, and organizational reputation. This article explains Incydr's trusted activity model and how it works as part of your insider risk strategy.
How Incydr determines trust
Incydr builds its risk detection foundation by first monitoring all file activity. When any possible exfiltration exposure is detected, it then applies trust to that event to determine whether it might be risky and thus should be prioritized for your attention.
Incydr uses two methods to evaluate whether an event qualifies as trusted activity:
- Defined trust uses the trusted domains, URL paths, workspaces, and IP addresses you define in Data Preferences to categorize the activity that takes place on those trusted destinations as trusted activity.
- Inferred trust matches activity detected on one of your authorized data connections with corresponding activity on a monitored endpoint.
When evaluating trust for an event, defined trust takes priority:
- Defined trust evaluation: Incydr first compares metadata collected about the event to any trusted entries in Data Preferences and any cloud aliases in user profiles. If any of the data matches your Data Preferences settings or cloud aliases, the event is trusted.
- Inferred trust evaluation: If no matching defined trust settings are identified, Incydr then attempts to match events occurring on your data connections to corresponding activity on a monitored endpoint. When matching events are identified, both the cloud or business tool event and the endpoint event are trusted.
- If trust cannot be established through either defined or inferred trust, the event is considered untrusted.
After Incydr determines that an event is not trusted, it applies risk settings and risk indicators to calculate the risk severity of the event. Risk severity and all related information about that untrusted activity is then displayed on security dashboards like the Risk Exposure and Insider Risk Trends dashboards and in alert notifications (when triggered by a corresponding alert rule). You can then investigate the activity further in Forensic Search to quickly respond to any possible exfiltration.
Incydr's trusted activity model automatically filters out trusted events to help you focus on possible risks. However, you can always view information about either trusted or untrusted events in Forensic Search with the Trusted activity filter.
Defined trust
Defined trust works best when approved corporate destinations can be clearly identified and differentiated from personal accounts. For example:
- A corporate Microsoft OneDrive account that uses a unique domain, such as
examplecorp-my.sharepoint.com, which is easily differentiated from personal accounts that use aonedrive.live.comdomain - A GitHub repository that uses a unique structure in the URL path, such as
https://github.com/examplecorp/repository/project1, which can be easily differentiated from other repositories using other structures - Your organization's corporate email domain (such as
@examplecorp.com), which is easily differentiated from personal @gmail.com or @outlook.live.com email accounts - Your organization's Slack workspace, which differs from the names of workspaces used for personal social communications
- Cloud aliases used by your employees on approved services, which may differ from their Code42 usernames
In order for defined trust to work, you must add trusted settings to the Trusted activity tab in Data Preferences. You define the cloud aliases used by your employees in their individual user profiles.
Inferred trust
Inferred trust secures your intellectual property by identifying when data moves outside your trusted boundary. It does so by matching file activity that occurs within an environment monitored by a Code42 data connection with corresponding activity involving that same file on a monitored endpoint.
Inferred trust can take up to one hour to match endpoint activity with corresponding cloud activity (or vice versa). If monitored cloud activity cannot be matched to a corresponding monitored endpoint event, Incydr infers that the file must have been moved to an unmonitored location and flags it as untrusted.
Inferred trust requires both of the following:
- The Code42 agent is installed on the employee endpoints that you want to monitor.
- Code42 is connected to your corporate environments via an authorized data connection and is scoped to monitor the same employees that have monitored endpoints.
No further configuration is required.
Inferred trust is best suited for these situations:
- Cloud storage services that provide similar structures for both personal and corporate accounts. For example, Google Drive doesn't provide details that defined trust requires to differentiate uploads to personal accounts from uploads to corporate accounts. Incydr's Google Drive data connection solves this problem by connecting to and directly monitoring your corporate environment—any Google Drive activity that Incydr flags as untrusted must then have taken place on a personal account or an unmonitored corporate account.
- Business services like Salesforce that house your vital business data in databases and reporting tools. By monitoring this environment directly, Code42 can identify when reports containing critical business data are downloaded to an unmonitored device. Without this level of monitoring, you might not know that a report had been downloaded to a personal computer or mobile device at all.
- As a backup and failsafe in case defined trust cannot be established or when trusted activity is not configured in Data Preferences.
Use cases
The examples below illustrate how Incydr determines whether an event is trusted using either defined or inferred trust.
Defined trust
Inferred trust
