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.
- 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 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 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 product plan.
| Box product plans | Google Drive product plans | Microsoft product plans |
|---|---|---|
|
Requires one of these Box product plans:
|
Requires one of these Google product plans:
|
Requires one of these Microsoft OneDrive cloud storage or Microsoft 365 business plans...
...or one of these Microsoft enterprise plans:
|
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 unsanctioned 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 indexing process
Code42 cannot index, 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 initial indexing take?
The length of time it takes for initial indexing 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 indexed 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 types in Forensic Search.
| Event Type | Description |
|---|---|
| New file |
A new file has been detected in the cloud storage environment.
During the initial indexing 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 indexing is establishing a baseline of your environment's current state. Accordingly, the totals displayed on risk detection lenses do not change or update during initial indexing as this baseline is established.
When a file for which sharing permissions have been set is created in a new location after initial indexing completes, Code42 captures both the new file event as well as any new exposure status for that file, as both the new file and its permission change are new events to the environment. |
| Modified |
An existing file in the cloud storage environment has been modified in some way.
|
| No longer observed | A file has been deleted, moved to the "trash" container, or otherwise removed from the cloud storage environment. |
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.
- Public via direct 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).
- Shared with corporate domain: 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 Public via direct 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 users: 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 Shared With Users 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 actor 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.
Depreciated and disabled sharing permissions may still appear in Forensic Search
To increase security, cloud storage providers may themselves depreciate sharing permissions so that they can no longer be selected or applied to files. For example, Google recently depreciated 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 depreciated 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 depreciated 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 depreciated 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 File exposure changed to or Source 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 under the Event, Cloud, and Exposure details in Forensic Search.
- As noted above, the Event Type in Event details identifies whether the file is new, has been modified, or is no longer observed in the environment.
- In Cloud details, pay attention to the Actor, Shared With Users, and File exposure changed to fields.
- Actor identifies the user who made the change to the file.
- Shared With Users identifies the users the file has been shared with. Users can only be listed here when they are specifically identified by the Shared with users sharing 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 Public via direct link or Shared with corporate domain sharing types.
- File exposure changed to indicates that the change resulted in a new or increased exposure for your organization, and lists the type of sharing added to the file that caused that increased exposure. If a change doesn't result in any increase in exposure, this field is blank. This field may also be blank when a file in Box or OneDrive environments inherits a permissions change from its parent folder.
- Exposure type in Exposure details lists the file's exposure status at the time the activity was detected. This always lists the file's current sharing type, regardless of whether that change increased the file's exposure.
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. |
Note that even though Eva has shared the file with others, Forensic Search doesn't indicate any new exposure and doesn't show the File exposure changed to field (because it is blank). Her share didn't increase the file's exposure 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. |
Her personal email address appears in the Shared With Users list, and both the File exposure changed to and Exposure Type fields show that the file is now shared with a user outside the company's trusted domains. |
| 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 permissions to "Anyone at Example with the link" using its connection to the organization's Google Drive environment. The Exposure Type field now indicates that the file is exposed to internal corporate employees as well as external users (Eva's personal email, in this case).
Note that the File exposure changed to field hasn't changed. Eva's new share (to other internal employees) did not result in a greater exposure than the file already has (due to her share to her personal email), so no increase in exposure is reported. |
| 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 both the File exposure changed to and Exposure Type fields indicate Public via direct link. |
