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:
To connect Code42 to a cloud storage environment for monitoring, see one of these articles:
Considerations
Roles and permissions
- Your product plan must include at least one cloud storage data connection. If your license expires, the cloud storage connection is deauthorized within 24 hours. Contact your Customer Success Manager (CSM) for assistance with licensing. If you're not sure how to reach your CSM, please contact our Customer Champions for support.
- To connect to a cloud storage environment, you must have the appropriate permissions in that environment as well as in Code42.
- Box: You must be a Box admin (or co-admin with the required permissions) to authorize the connection to Code42.
- Google Drive: You must be a Google Workspace administrator with a Super Admin role to authorize the connection to Code42.
- Microsoft OneDrive: You must be a OneDrive global administrator to authorize the connection to Code42.
- If you need to change the credentials or other account information used to authorize Code42's connection to the cloud storage environment, temporarily deauthorize the cloud storage connection, then reauthorize with the new account information.
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.
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:
|
Requires one of these Google plans:
|
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
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.
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.
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.
|
| 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.
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 File, Filename 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.
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. |
|
| Eva shares the presentation with her colleagues, developers Taylor and Matthias, for review and feedback. |
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. |
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. |
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. |
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. |
