Trusted activity

Overview

Use Trusted activity settings to define domains, URLs, Slack workspaces, cloud accounts, and Git repositories you trust.

Adding trusted activity prevents file activity in these locations from appearing on dashboards, user profiles, and alerts.

Trusted file activity is still captured and searchable in Forensic Search.

Considerations

To use this functionality, your role must have permissions to view and modify data preferences.

How it works

  • File events are considered trusted when an entry in your list of trusted activity matches file event metadata associated with the event. Metadata evaluated for trust includes: browser tab titles, URLs, Git URIs, account names, usernames, and email addresses. 
  • If there is more than one domain associated with an event, all domains must be included in your list of trusted domains for the event to be trusted. If any domain associated with event is not in your list of trusted domains, the event is not trusted.
  • Trusted file activity is excluded from:

Configure trusted activity

To access trusted activity settings:

  1. Sign in to the Code42 console.
  2. Navigate to Administration > Environment > Trusted activity.

Trusted activity list

Item Description
a Settings

Trust recommendation settings provide the option to specify one or more company names. Adding a company name helps improve the quality and relevance of trust recommendations by prioritizing locations that include your name. This may indicate the location is acceptable to trust.

Add multiple names if different variations are used across your internal systems (for example, "Acme" and "Acme Co"). You can add up to 10 different names.

Company name values are also automatically added as available filters on the Recommendations tab.

b Add trusted activity

Click to add trusted activity and select a type:

Domain

Trusts a wide variety of activity across an entire domain, including files uploaded via a web browser, sent from cloud sync apps installed on user devices, uploaded via Git push, and shared via cloud or email services monitored by Incydr. See Domain below for complete details.

Specific URL path

Trusts browser uploads to only part of a domain. For example, adding the URL path github.com/company trusts uploads only to the "company" repository and not to all of github.com. See Specific URL path below for complete details.

Slack workspace

Trusts files uploaded in a specific Slack workspace. See Slack workspace below for complete details.

Account name
OneDrive and Dropbox only
For cloud sync apps installed on user devices, trusts activity in a specific account. For example, specifying the name of your corporate account enables you to trust that activity, without trusting activity in personal accounts. See Account name below for complete details.

Git repository URI

Trusts pushes to specific repositories via Git. See Git repository URI below for complete details.

Add trusted activity directly from file event details
From the Risk section of the file event details, click the add trust icon Add trust shield icon next to any untrusted value to add it to your list of trusted activity for future events.
 

Top recommendations

(not pictured)

Displays recommended trust settings to review and update based on your existing list of trusted activity. 

Once you complete all recommended items, this section no longer appears. 

c Trusted activities

Displays all trusted items (this tab).

d Recommendations

Displays activities that frequently generate untrusted events, with the option to add the item to trusted activity. See Recommendations below for details.

e Filter Filter the list by trusted activity type.
f Trusted activity The specific value that is trusted.
g Applies to

Indicates if the entry applies to a Domain, Specific URL path, Slack workspace, Account name, or Git repository URI.

h Description An optional field to provide additional context or details.
i Last modified

Indicates the time this entry was last modified and the user who made the change. File activity is trusted starting the date it is added to this list. Previous file activity is considered untrusted.

To see what changed, review the Audit Log and filter for Domain changed, Slack Workspace changedURL changed, or Git repository changed events.

j Edit Click to edit the trusted activity value and/or the description.
k Actions Click to delete this entry.

Recommendations

Review activities that frequently generate untrusted events and quickly add them as trusted activity. Adding trusted activity reduces noise by removing file activity in these locations from alerts, dashboards, and user profiles. The list of recommendations updates regularly, based on activity in your environment.

Trust recommendations tab

Item Description
a Trusted activities Displays all items that are already trusted. 
b Recommendations Displays activities that frequently generate untrusted events (this tab).
c All recommendations List of recommendations based on activity in your environment.
d Declined recommendations

Recommendations you previously declined to trust.

e Search Enter a string to filter the list of recommendations. For example, enter your company name to view only recommendations with your name in them.
f Filter Filter the list by location type (Domain, Specific URL path, Slack workspace, Account name, or Git repository URI) and any company name values entered in Settings.
g Filtered by

Indicates filters applied to the list of recommendations. Click "x" to remove a filter.

h Recommendation

Specific value to evaluate for trust. Click the checkbox next to multiple items to quickly add or decline all selected recommendations. 

Note: Bulk actions are not supported for account name recommendations because they require additional configuration. (To trust an account name, you must also select a specific cloud service.)

i Applies to

Indicates if the entry applies to a Domain, Specific URL path, Slack workspace, Account name, or Git repository URI.

j Users Indicates the number of users with activity at this location over the past 30 days. Locations with a higher user count indicate the activity is more common, which may suggest it's acceptable to trust.
k Events

Indicates the number of individual events at this location over the past 30 days.

l Date count Indicates the number of days with activity at this location over the past 30 days. Locations with a higher date count indicate the activity is more common, which may suggest it's acceptable to trust.
m Add to trusted activity Add_to_trusted_activity Click to add the recommendation to your list of trusted activity.
n Decline and remove from list Decline_and_remove_from_list Click to decline the recommendation. Click the Declined Recommendations tab to view all declined items
o View in Forensic Search Magnifying_glass View a list of file events for the suggested item. Reviewing the detailed file metadata can help you determine if the location should be trusted or not.

 

Domain

Adding trusted activity for a domain gives you the option to trust a wide variety of activity across the domain, including files uploaded via a web browser, sent from cloud sync apps installed on user devices, uploaded via Git push, and shared via cloud or email services monitored by Incydr.

Maintain confidentiality for users reporting misconduct
If your organization has established processes for users to report unethical behavior, harassment, discrimination, or other types of misconduct, consider adding the associated URLs to your list of trusted domains. For example, adding report-misconduct.example.com would prevent file activity on that domain from appearing on Code42 dashboards, user profiles, and alerts.
Trusted domain settings

Watch the video below for an overview of how to define a trusted domain. For more videos, visit the Code42 University.

Syntax and formatting requirements
  • Do not include https:// .
  • Including www is optional. The www prefix is ignored when evaluating trust.
  • Only the domain is evaluated for trust. The protocol (https://) and characters after the top-level domain (TLD) are ignored. For example, for file activity on https://subdomain.corp.example.com/pages, only subdomain.corp.example.com is evaluated for trust.
  • For email activity, a value of example.com trusts activity from all users with email addresses on the example.com domain. Trusting specific email addresses is not supported.
  • Optionally, use the asterisk (*) character as a wildcard for partial domain names. For example, enter *.example.com to trust all subdomains of example.com. See more guidance and warnings about wildcards below.
  • Review the Recommendations and Examples tabs on the add/edit screen for additional guidance.

Trusted scope

After entering the domain and optional description, select exactly which types of domain activity to trust:

  • Files uploaded to this domain via a web browser: Activity is trusted if the domain is included in the browser URL or tab title. 
  • Files synced to cloud storage by desktop apps: Activity is trusted if the username signed in to the cloud sync app is on the domain. Click Edit to adjust which specific apps are trusted.
  • Files shared from a cloud storage data connection to users on this domain: Activity is trusted if the user it's shared with is on this domain. Click Edit to define which cloud storage services are trusted. 
  • Files shared from an email data connection to users on this domain: Activity is trusted if the email recipient is on the domain. Click Edit to choose which email services are trusted.
  • Files uploaded via Git push: Activity is trusted for Git push events to this domain.
Editing trusted scope details
Clicking the Edit link enables you to better identify risk in unmonitored locations. For example, if your company's only approved cloud storage solution is OneDrive, deselect Box and iCloud to define that activity as untrusted, even if the email address signed in to the account is on your domain.

Wildcards

Use wildcards carefully to minimize risk
Using a wildcard character may lead to unintentionally trusting unknown or malicious domains.

A trusted domain value of example* trusts not only example.com, but also any domain starting with example, such as example.fake.com, examplenotyourrealdomain.com, and example.info.

To trust both a parent domain and all subdomains, do not use an overly inclusive wildcard value, such as *example.com. Instead, add these two values to minimize risk:

  • example.com
  • *.example.com

Since the first entry does not include a wildcard, it only trusts activity that matches the example.com domain exactly. In the second entry, including a period (.) after the wildcard ensures only subdomains of your legitimate domain are trusted.

Trusted domain examples

The table below provides examples of whether file activity is trusted based on the combination of the trusted domain entry and where the file activity occurred.

  • Yes = Activity on this domain is trusted for the supplied trusted domain entry
  • No = Activity on this domain is not trusted for the supplied trusted domain entry                                                            
  Trusted domain entry
   <<<   More secure                                                                                    Less secure  >>>
Activity on: example.com *.example.com example *example.com example* *example*
www.example.com Yes No No Yes Yes Yes
https://subdomain.example.com No Yes No Yes No Yes
www.not-example.com No No No Yes No Yes
www.example.fake.com No No No No Yes Yes
first.last@example.com Yes No No Yes Yes Yes

Specific URL path

Specific URL path entries trust activity for only part of a domain. For example, adding the URL path github.com/company trusts uploads only to the "company" repository and not to all of github.com.

  • The combination of domain and path define trusted activity.
  • All sub-directories of a path are also trusted. For example, an entry of github.com/company also trusts uploads to github.com/company/repository.
  • The path portion of the URL can contain wildcards (*), but the domain cannot include wildcards.
  • Do not include the protocol or query parameters. They are ignored when evaluating trust.

Example of URL structure showing the protocol, domain, path, and parameters. Only the domain and path sections of the URL are evaluated. The protocol characters at the beginning, such as “https://“, and query parameters at the end following a ? are ignored. For example, in the URL https://github.com/company/respository/commit/abc?branch=123, only the domain and path of github.com/company/respository/commit/abc are evaluated.

Watch the video below for an overview of how to define a trusted specific URL path. For more videos, visit the Code42 University.

Slack workspace

Trusting only specific Slack workspaces enables you to better identify risk in external Slack workspaces you don't control. For example, adding your corporate Slack workspace trusts file activity only within that workspace. Files shared in other workspaces are not trusted.

  • Only enter the workspace name (for example, "Acme Co."). Do not enter the workspace URL.
  • Wildcards are not supported in workspace names. If you include the * character, it is evaluated as part of the workspace name.

Watch the video below for an overview of how to define a trusted Slack workspace. For more videos, visit the Code42 University.

Account name

OneDrive and Dropbox only

Add your corporate cloud account name to trust file activity only within that account. This helps you better identify risk in personal accounts you don't control.

OneDrive

To trust a OneDrive account:

  1. On a user device, find the OneDrive sync folder for the corporate account you trust. For help locating this folder, visit Microsoft Support.
  2. In the Code42 console:
    1. From the list of cloud services to trust, select OneDrive.
    2. Enter the complete folder name in the Account name field. For example, OneDrive - Acme Co.
    3. Click Save.
Dropbox

To trust a Dropbox account:

  1. Sign in to dropbox.com with your administrator credentials.
  2. Select Admin console > Settings > Team profile. Note the Display name.
  3. In the Code42 console:
    1. From the list of cloud services to trust, select Dropbox.
    2. In the Account name field, enter the Display name plus the word "Dropbox." For example, if your Display name is "Acme Co," enter "Acme Co Dropbox".
    3. Click Save.

Trusted activity - Account name

Account name considerations
  • For OneDrive, trust is only evaluated for OneDrive for Business accounts. Personal accounts cannot be trusted.
  • For OneDrive, the sync folder name on user devices is determined by the name in your Microsoft console at the time the sync folder was created. Therefore, if your Microsoft account name has ever changed, you may have devices with different sync folder names. Add a separate trusted activity entry for each unique sync folder name in your environment.
  • Wildcards are not supported in account names. If you include the * character, it is evaluated as part of the account name.
  • Requires insider risk agent version 1.6.0 or later, or backup agent version 10.3.0 or later.

Git repository URI

GitHub use case
To trust a GitHub account or repository, select Top use cases > GitHub. Choose all or a specific repository, then enter the name. Upon clicking Save, three distinct trust entry variations are added automatically to cover different URL and URI formats.

For other Git tools, follow the examples below to manually add separate Specific URL path and Git repository URI entries.

Add a Git repository URI to trust Git pushes to this location.

  • All sub-directories of the repository are also trusted.
  • The URI scheme, user, and the trailing “.git” are ignored. For example:
    • To trust all repositories in your company account at ssh://git@example.com:account/, enter example.com:account/ 
    • To trust a specific repository at ssh://git@example.com:account/repository.git, enter example.com:account/repository
  • To trust browser uploads to this location, you must also add a Specific URL path entry.

Trusted activity recommendations for source code repositories

How you configure trust for Git activity varies based on your source control application and repository locations.

General guidelines
  • To trust Git activity for all repositories on a domain, use the Domain trusted activity type and select the trusted scope Files uploaded via Git push. You do not need to specify individual URI values. The Domain entry applies trust to both Git browser uploads and Git push activity.
  • To trust only some locations on a domain, you must add two trusted activity types:
    • A Specific URL path entry to trust browser uploads
    • Git repository URI entry to trust Git push activity
Specific examples
  • Github: Add trusted activity entries for both Specific URL path and Git repository URI.
    Select Top use cases > GitHub to simplify the configuration and automatically create all required entries.
  • Gitlab: Add a single Domain trusted activity entry. If the domain is already on your list of trusted activity, click the edit icon and then select Files uploaded via Git push in the list of Trusted scope options.
  • Azure DevOps: Add trusted activity entries for both Specific URL path and Git repository URI.
  • BitBucket (cloud): Add trusted activity entries for both Specific URL path and Git repository URI based on your workspace name.
  • BitBucket (on-prem): Add a single Domain trusted activity entry. If the domain is already on your list of trusted activity, click the edit icon and then select Files uploaded via Git push in the list of Trusted scope options.

Identify sources with high-value data

Available for domains, URL paths, Slack workspaces, Account names, and Git repositories.

The Is this also a high value source of company information setting enables you to define if files acquired from this trusted location are a potential risk if they are exfiltrated later.

  • Yes: Events for files acquired from this location and later sent to an untrusted destination have a risk score and source risk indicator applied. This enables you to trust uploads to a destination, but still apply risk to files downloaded from that destination and later moved to unmonitored or untrusted locations.
  • No: Events for files acquired from this location and later sent to an untrusted destination are not identified as a risk.