Skip to main content

Who is this article for?
Find your product plan in the Code42 console on the Account menu.

Incydr Professional, Enterprise, and Gov F2
Incydr Basic, Advanced, and Gov F1
Other product plans

Incydr Professional and Enterprise, yes.

Incydr Basic and Advanced, yes.

CrashPlan Cloud, no.

Other product plans, yes.

CrashPlan for Small Business, no.

This article applies to Code42 cloud environments.

HOME
GETTING STARTED
RELEASE NOTES
FAQs
APIs
SYSTEM STATUS
Code42 Support

Trusted activity

Overview

Use the Data Preferences settings for Trusted activity to define domains and Slack workspaces you trust.

Adding trusted domains and Slack workspaces prevents file activity in these locations from appearing on dashboards, user profiles, and alerts. However, trusted file activity is still 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 for these fields: Active tab titles and URLs, Sync Username, Shared With (for cloud data sources), and Recipients (for email data sources). 
  • 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 > Data Preferences.
  3. Select the Trusted activity tab.

When adding or editing trusted activity, review the Add trusted activity guidelines in the table below. For domains and URL paths, you can also review the Recommendations and Examples tabs on the add/edit screen for additional guidance.

Trusted activity list

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.
Item Description
a 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, and shared via cloud or email services monitored by Incydr.

  • 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 below for more guidance and warnings about wildcards.

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.

  • 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.

Slack workspace

Trusts files uploaded in a specific Slack workspace.

  • Only enter the workspace name (for example, "Acme Co."). Do not enter the entire workspace URL.
  • Wildcards are not supported in workspace names. If you include the * character, it is evaluated as part of the workspace name.
b Trusted activity The location of activity to be trusted.
c Applies to

Indicates if the entry applies to a Domain, Specific URL path, or Slack workspace.

d Description An optional field to provide additional context or details.
e 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.

 

Applies to the value being evaluated for trust. Updating only the description text does not change the Last modified date.

f Edit Click to edit the trusted activity value and/or the description.
g Actions Click to delete this entry.
Use wildcards carefully to minimize risk
Using a wildcard character may lead to unintentionally trusting unknown or malicious domains. For example, a trusted domain value of example* would trust 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
  • Was this article helpful?