As part of your insider risk detection strategy, allow Code42 access to your cloud services. Once connected, Code42 monitors the cloud service 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 environment for monitoring, see one of these articles:
Roles and permissions
- Your product plan must include at least one cloud service. If your license expires, the cloud service 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 the cloud service, you must have the appropriate permissions in the cloud service 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 service, temporarily deauthorize the cloud service, then reauthorize with the new account information.
- Cloud services are not available in the Code42 federal environment.
- Code42 can monitor a maximum number of drives in a cloud service, depending on vendor.
- Box: 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.
- OneDrive: 55,000 drives
- 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 service is solely granting permission for Code42 to read specific data in your environment.
Code42 temporarily streams files from your cloud or email service to the Code42 cloud to calculate the file hash. This may be reported as users downloading files.
Code42 never stores file contents or writes them to disk during this process.
Supported cloud service vendor plans
Code42 can only connect to your cloud 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:
...or one of these Microsoft enterprise plans:
How is cloud service monitoring different?
You may already be familiar with how Code42 monitors file activity on employee devices. Code42's monitoring of cloud services 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 service monitoring: Cloud service 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 service connections track files that users share with others in your organization's cloud drives to detect unauthorized external access.
Initial indexing process
Once you complete authorization, Code42 starts monitoring your environment for file activity right away. At the same time, Code42 begins indexing the drives in that environment. During this process, Code42 discovers all in-scope drives and indexes all of their files. If a file is not yet indexed and file activity occurs, the file is immediately indexed and subsequent file activity is sent to Code42. The time to complete the initial indexing of a drive is directly related to the number of files within the drive, not the size of the files.
As Code42 progresses through initial indexing, information about the drives that have been processed is listed under Status on the cloud service'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 indexed compared to the number that have completed the initial indexing process. For Google Drive, a second section repeats these details for shared or team drives.
To speed up this process, file hashes are omitted. As a result, you see the message Hash Unavailable. File not modified since initial extraction in the MD5 Hash and SHA256 Hash fields displayed for these files in Forensic Search. However, the files will be hashed when new file activity occurs.
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.
- For environments that contain hundreds of drives, initial indexing may take between 24 and 72 hours depending on the number of files in each user's drive.
- For environments that contain thousands of drives, initial indexing completes over a longer period. Typically, drives in larger environments complete the indexing 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 indexing 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 indexed immediately.
Activity Code42 monitors in cloud services
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 service 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.
When Code42 detects basic file events (such as file additions, modifications, or deletions) in your cloud environment, it reports that activity under specific event types in Forensic Search.
A new file has been detected in the cloud service.
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.
An existing file in the cloud service has been modified in some way.
|No longer observed||A file has been deleted, moved to the "trash" container in the environment, or otherwise removed from the cloud service.|
Your employees use the tools available in the cloud service 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 the various cloud services' interfaces. This sharing type is shown as follows in the cloud service:
- 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 service (via automated emails, for example) or external tools outside the cloud service (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 service:
- 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 service 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 service:
- 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.
Files inherit the sharing permissions of their parent folders in your cloud 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 service 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 services 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 service environments by disabling certain sharing methods to prevent users from applying those sharing permissions to files at all.
Most cloud services 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 services 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 service 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 service 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 service 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 services 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 service file activity results
Information about cloud service 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 services).
Because other sharing permissions simply generate a link that can be shared using tools within or outside the cloud service (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.
There's not always a strict one-to-one relationship between the actions a user takes on a file in a cloud service 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 a cloud service. 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 service may appear as one "file modified" event in Forensic Search.
Throttling of API requests by the cloud service 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 the cloud service to be displayed in fewer events in Forensic Search.
Use case: Cloud service 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 domains 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.