Skip to main content

Who is this article for?

Incydr Professional, Enterprise, Horizon, and Gov F2
Incydr Basic, Advanced, and Gov F1

Find your product plan in the Code42 console on the Account menu.

Instructor, no.

Incydr Professional, Enterprise, Horizon, and Gov F2, yes.

Incydr Basic, Advanced, and Gov F1, yes.

CrashPlan Cloud, no.

Retired product plans, yes.

CrashPlan for Small Business, no.

HOME
GETTING STARTED
RELEASE NOTES
FAQs
APIs
SYSTEM STATUS
Code42 Support

Cloud storage data connections overview

Overview

As part of your insider risk detection strategy, allow Code42 access to your corporate cloud storage environments. Once connected, Code42 monitors that cloud storage environment to capture when a user:

  • Creates or uploads a file
  • Shares a link to a file
  • Shares a file directly with users inside or outside your organization
  • Deletes a file
  • Modifies a file's contents, name, or location

To connect Code42 to a cloud storage environment for monitoring, see one of these articles:

Considerations

Roles and permissions

Limitations

  • Code42 can monitor a maximum number of drives in a cloud storage environment, depending on vendor.
    • Box and Microsoft OneDrive: 500,000 drives
    • Google Drive: 55,000 drives
      Shared drives in Google Drive do not contribute to this limit. Code42 can monitor unlimited shared drives in Google Drive.
  • Code42 prioritizes file-based monitoring. Detection of folder sharing permissions changes in Box and OneDrive environments may not be reflected as file activity or may be delayed.
  • Drives and files owned by suspended (Google Drive and Box) or blocked (OneDrive) users may still generate events if they are shared with others. When other users interact with those shared drives or files, those users may generate file activity that is captured by Code42. No new activity is generated by the suspended or blocked user.

Code42's access to data

  • Once authorized, Code42 has access to metadata on users, files, and drives.
  • Code42 does not store information about the administrator account used for authentication. The administrator who authorizes the cloud storage connection is solely granting permission for Code42 to read specific data in your environment.
Monitoring and alerting tools may report download activity
When ongoing file activity is detected, Code42 temporarily streams files from your cloud storage or email service to the Code42 cloud to calculate the file hash. (Code42 does not calculate hash value during the initial inventory process.) This may be reported as users downloading files. The requesting service's IP address may point to Microsoft Azure hosts.

Code42 never stores file contents or writes them to disk during this process.

Supported cloud storage vendor plans

Code42 can only connect to your cloud storage environment when supported by that vendor's plan or license.

Box Google Drive Microsoft OneDrive

Requires one of these Box plans

  • Business
  • Business Plus
  • Enterprise
  • Enterprise Plus

Requires one of these Google plans:

  • Business Standard
  • Business Plus
  • Enterprise Standard
  • Enterprise Plus

Requires a Microsoft license or subscription that includes:

How is cloud storage monitoring different?

You may already be familiar with how Code42 monitors file activity on employee devices. Code42's monitoring of activity in cloud storage differs in that it primarily detects changes in sharing permissions for files stored in your organization's cloud drives. This detection helps to identify possible exfiltration of files or unauthorized user access to those files. These two types of monitoring are not synonymous.

  • Endpoint monitoring: Desktop sync apps (such as the Google File Stream app) installed on endpoints allow users to sync new or modified files on their devices with cloud-based storage for on-demand access anywhere. Code42 monitors and detects such activity with its endpoint monitoring tools.
  • Cloud storage monitoring: Cloud storage applications (for example, a corporate Google Drive or Microsoft OneDrive that users sign into using a web browser) allow users to share files in that environment with other collaborators using the tools in the browser. Code42 monitors and detects this activity directly through its authorized connection to your organization's cloud environment without involving employee endpoints at all.

Together, this monitoring gives you a fuller picture of data movement. Code42's endpoint monitoring tracks file activity to and from employee endpoints, while its cloud storage connections track files that users share with others in your organization's cloud drives to detect unauthorized external access.

Initial inventory process

Once you complete authorization, Code42 starts monitoring your environment for file activity right away. At the same time, Code42 begins taking an inventory of the drives in that environment. During this process, Code42 discovers all in-scope drives and inventories all of their files. If a file is not yet inventoried and file activity occurs, the file is immediately inventoried and subsequent file activity is sent to Code42. The time to complete the initial inventory of a drive is directly related to the number of files within the drive, not the size of the files.

As Code42 progresses through the initial inventory, information about the drives that have been processed is listed under Status on the cloud storage's details panel. This status lists the total number of drives in your environment that are being monitored for ongoing activity. It also shows how many of those drives are still being inventoried compared to the number that have completed the initial inventory process. For Google Drive, a second section repeats these details for shared drives.

To speed up this process, file hashes are omitted. As a result, you see the message Hash Unavailable. File not modified since initial inventory in the MD5 Hash and SHA256 Hash fields displayed for these files in Forensic Search. (Google may provide an MD5 hash value if it is available.) Files are hashed when new file activity occurs.

OneDrive shared libraries are not inventoried, discovered, or monitored
Code42 cannot inventory, discover, or monitor shared libraries in your OneDrive environment. While you can create a shared library within OneDrive, such libraries are actually created as Team Sites in SharePoint. Because Code42 can only monitor drives in OneDrive (and not Team Sites in SharePoint, Teams, or Outlook), any shared libraries in your environment are excluded. 

How long does the initial inventory take?

The length of time it takes for the initial inventory to complete is dependent on the size of your environment.

  • For environments that contain hundreds of drives, the initial inventory may take between 24 and 72 hours depending on the number of files in each user's drive. The inventory process can take longer if Code42's connection to the cloud environment is throttled. Throttling may occur for these reasons:
    • Google Drive connections can be throttled based on the number of requests made by both the Code42 service per user drive and by all services in the account as a whole
    • OneDrive connections can be throttled based on all requests (including those from Code42) for the account as a whole
    • Box connections can be throttled based on requests made by Code42 per user drive
  • For environments that contain thousands of drives, the initial inventory completes over a longer period. Typically, drives in larger environments complete the inventory process over these time frames:
    • 60% of total drives complete between 24 and 72 hours
    • 25% of total drives complete between 3 and 5 days
    • 15% of total drives complete between 6 and 10 days

Because Code42 monitors your environment for activity while completing an inventory of users' drives, it detects newly uploaded or created files typically within minutes. It can take up to 20 minutes for file events in your environment to appear in search results in Forensic Search or to trigger any alert rules that you have set up. New file events may take up to an hour to appear on the Risk Exposure dashboard or in the User Profile

In Google Drive and One Drive environments, Code42 discovers new drives that have been added to your environment within 8 hours. For Box, Code42 discovers new drives typically within a few minutes. After discovery, new drives are inventoried immediately.

Activity Code42 monitors in cloud storage

As with files on endpoints, Code42 detects when users add, edit, copy or move, and remove or delete files stored in drives in your cloud storage environment. And just as the cloud environment itself enhances productivity by allowing your employees to collaborate by sharing files, Code42 secures that collaboration by detecting when files are shared publicly or with external users to identify possible unauthorized access. Code42 displays information about all detected file events and file sharing permissions changes in Forensic Search for further investigation.

File events

When Code42 detects basic file events (such as file additions, modifications, or deletions) in your cloud storage environment, it reports that activity under specific event actions in Forensic Search.  

Event action Description
Created

A new file was detected in the cloud storage environment.

  • Code42's connection to your environment was just authorized, and Code42 is completing an inventory of all of the files in the environment (initial inventory).
  • A new file was uploaded or created in the environment.
  • A file was copied from one location in the environment to another. The copy in the new location shows as a new file.

During the initial inventory process, Code42 detects each file's current sharing permissions. However, these permissions are not identified as causing any new exposure in Forensic Search because the initial inventory is establishing a baseline of your environment's current state. Accordingly, the totals displayed on watchlists do not change or update during the initial inventory as this baseline is established.

 

When a file for which sharing permissions have been set is created in a new location after the initial inventory completes, Code42 captures both the new file event as well as any new sharing risk for that file, as both the new file and its permission change are new events to the environment.

Inventoried Code42 inventoried an existing file in the cloud storage environment automatically after the connection was authorized. These events do not represent user activity. Instead, the file event metadata for inventoried events represent a point-in-time analysis of the file's current state.
Modified

An existing file in the cloud storage environment was modified in some way.

  • The file's contents were updated
  • The file was renamed
  • The file was moved from one folder to another
  • A new version of an existing file was uploaded to the environment

Deleted A file was deleted, renamed, moved to a different location or to the "trash" container, or otherwise removed from the cloud storage environment.
Shared A file in the cloud storage environment was shared as a link or directly with one or more users. Review the Share type and the Destination user fields in the event details for more information about its sharing permissions.

File sharing

Your employees use the tools available in the cloud storage environment to share files with other collaborators. These tools allow employees to change the permissions on a file, which then allow other users to access it via a link. Code42 detects these permissions changes and displays them in Forensic Search.

Types of sharing

Because Box, Google Drive, and OneDrive use different terminology for sharing permissions in these environments, this terminology has been normalized in Forensic Search to the following sharing types.

  • Anyone with the link: Anyone who has the link (for example, via an email that contains the URL or through a message from your organization's messaging service) can access the file. This sharing type is normalized from the methods used to share files in various cloud storages' interfaces. This sharing type is shown as follows in the cloud storage environment:
    • Box: People with the link
    • Google Drive and OneDrive: Anyone with the link

    Because this type of sharing simply generates a link by which the file can be accessed, there's no way to identify the specific users to which that link has been shared. Instead, the link is shared with others using tools in the cloud storage environment (via automated emails, for example) or external tools outside the cloud environment (by copying and pasting the link in an email or text message, for example).

  • Anyone in your organization: Any employee of your organization who has the link can access the file. This sharing type is shown as follows in the cloud storage environment:
    • Box: People in your company
    • Google Drive: <Your organization's Name> 
      This changes to "Anyone at <your organization> with the link" when the file's permissions are viewed later in Google Drive.
    • OneDrive: People in <your organization> with the link

    As with the Anyone with the link sharing type, this type of sharing simply generates a link by which the file can be accessed. Security is controlled by the cloud storage environment by requiring employees to log in, and once they're authenticated as a member of your organization, they can open the file. Because the link is shared with others in your organization using email or text messages, there's no way to capture the specific users with which the file has been shared.

  • Shared with specific people: Only the specified people that the file was shared with can access the file. This sharing type is shown as follows in the cloud storage environment:
    • Box: Invited people only
    • Google Drive: Restricted
    • OneDrive: Specific people

    Because this sharing method explicitly identifies the users who can access the file within your environment, Code42 can capture those email addresses and display them in User under Destination in Forensic Search.

Inherited permissions

Files inherit the sharing permissions of their parent folders in your cloud storage environment. For example, Rahul shares the entire \Templates folder with his colleagues in Marketing to enforce a consistent look and feel for the presentations they all create. All of the child templates (for presentations, documents, and so on) in this folder inherit that permission and can be accessed by those users, in addition to whatever sharing permissions those files themselves have.

Not all cloud storage vendors directly report permissions that a file inherits from its parent folder. For this reason and because Code42 prioritizes monitoring file activity over folder activity, file events for permissions changes due to inherited permissions may be delayed in appearing in Forensic Search. Additionally, Forensic Search may not attribute the inherited permission to an user to avoid incorrectly correlating that inherited activity.

Inbound vs. outbound shares

Code42 does not currently fully support inbound shares, only outbound shares.

  • Inbound share: Someone outside of your organization has shared a file with you or your employees. For example, an external prospect shares sensitive network connection details with one of your developers for assistance with setting up a custom application. While inbound shares may still represent a risk (your organization may have access to another company's information that maybe it shouldn't), it does not pose an insider risk to the security of your information that Code42 is specifically developed to address.
  • Outbound share: You or one of your employees shares a file with someone outside your organization. For example, one of your sales representatives emails a link to an internal sales proposal containing unreleased financial data to a former colleague for review and advice. This represents exactly the insider risk (potential loss of important information due to an internal actor's actions) that Code42 is designed to detect and identify.

Deprecated and disabled sharing permissions may still appear in Forensic Search

To increase security, cloud storage providers may themselves deprecate sharing permissions so that they can no longer be selected or applied to files. For example, Google recently deprecated the "public on the web" sharing option that both created a link to a file and made it available to search engines for indexing and searching. This sharing option resulted in open access: anyone using the correct search terms could directly locate and open the file in the Google search engine. Likewise, security administrators can choose to harden security in their cloud storage environments by disabling certain sharing methods to prevent users from applying those sharing permissions to files at all.

Most cloud storage providers do not retroactively remove or change the permissions for any files that already use deprecated or disabled permissions. For files that use a disabled permission, cloud storage providers may prevent certain users from accessing that file by imposing more restrictive security settings when a user clicks the link, but they generally do not change the file's sharing permission itself. Therefore, files that already use deprecated or disabled permissions are maintained with those settings, and updates to these files within the cloud storage environment is reported in Forensic Search as public share events. Keep in mind that copying a file will also apply any deprecated or disabled sharing permissions used by the original file to the new copy.

Cloud storage file activity in Forensic Search

Code42 displays all file activity detected in your cloud environment in Forensic Search to aid investigations.

Searching in Forensic Search

To search for general cloud storage file activity in Forensic Search, use the Share type or Event observer filters. You can add all of the sharing types or all cloud storage providers to these filters to locate all of the activity detected in your cloud environments, or you can search only for activity matching specific types or environments.

Cloud sharing filters in Forensic Search

To narrow your search further, add additional filters for details that you know about the file, such as the filename, actor, or hash value.

Cloud storage file activity results

Information about cloud storage file activity is listed in several fields in Forensic Search.

  • Review the Event section for basic details about what happened.
    • As noted above, Event action identifies whether the file is new, was modified, was shared, or was deleted from the environment.
    • If the file was shared, Share type identifies the file's sharing permission.
    • Event observer identifies the environment in which the file was shared, created, or modified.
  • Under User, the Username identifies who made the change to the file.
  • Under FileFilename lists the name of the file and allows you to copy the link to the file for further investigation. If you have the Security Center - Restore role, you can click View file to request temporary view access to the file if you cannot access it.
  • Under Destination, User identifies the users the file has been shared with. Users can only be listed here when they are specifically identified by the Shared with specific people share type (by selecting the Invited people only (Box), Restricted (Google), or Specific people (OneDrive) permissions in those cloud storage environments).

    Because other sharing permissions simply generate a link that can be shared using tools within or outside the cloud environment (such as email or text messages), there's no way to capture the users with whom that link has been shared for the Anyone with the link or Anyone in your organization sharing types.

A single file event in Forensic Search may represent more than one action in cloud storage
There's not always a strict one-to-one relationship between the actions a user takes on a file in your corporate cloud storage environment and the file event representing those actions in Code42. After detecting activity, Code42 makes a best effort to interpret the user's actions on a file in cloud storage. Code42 may combine several of those actions into one file event to more efficiently and effectively display those details. For example, a user modifying a file repeatedly a few seconds apart in the cloud storage environment may appear as one "file modified" event in Forensic Search.

Throttling of API requests by the cloud storage vendor can also slow Code42's metadata collection and affect how file events are displayed in Forensic Search. Both this throttling and Code42's interpretation of actions can cause multiple actions in cloud storage to be displayed in fewer events in Forensic Search.

Use case: Cloud storage events in Forensic Search

The following table walks through a common cloud sharing use case and shows examples of how such activity appears in Forensic Search. (See more use cases in Forensic Search use cases.) Note that Forensic Search automatically hides fields that are blank or that do not have any data. In addition, to focus on how cloud activity is displayed in Forensic Search, the examples below show only the sections most applicable to those results.

Activity As displayed in Forensic Search
Eva creates a new presentation to describe new product features and saves it in the corporate \ProductRoadmap cloud directory.

Event details for a new cloud storage file

Eva shares the presentation with her colleagues, developers Taylor and Matthias, for review and feedback.

Event details for a cloud file shared with trusted users

Even though Eva has shared the file with others, her share doesn't cause additional risk because both developers' email addresses use the internal "@example.com" domain that is included on the company's trusted activity list.

She's under a tight deadline, so Eva adds her personal email address to the presentation so that she can work on it at home in the evening.

Event details for a cloud file shared with untrusted users

For this new sharing event, the Trusted activity and Share type fields show that the file has been newly shared with a specific user outside the company's trusted domains and her personal email address appears in the Destination User field.

 

Note that the file is still shared with Taylor and Matthias. This event shows only the new sharing that Eva added.

After creating a final draft, she shares it with her company's #DevManagers Slack channel to collect any final comments prior to their sales kickoff.

Event details for a cloud file shared within your organization

When Eva shared the file with the channel, Slack updated the file's sharing permissions to "Anyone at Example with the link" using its connection to the organization's Google Drive environment. The Share type field for this event indicates that the file is shared with Anyone in your organization.

Kickoff was a success! Marketing moves Eva's presentation to a public folder to support training for internal sales representatives and external channel partners.

Event details for a cloud file shared publicly

The folder to which Eva's presentation was moved in the company's Google Drive environment has a permission setting of "Anyone with the link." Eva's presentation inherits this permission (along with the permissions it already has), and thus the Share type for this event indicates Anyone with the link.

  • Was this article helpful?