Cloud storage activity monitored by a Code42 data connection
Overview
When you monitor a Box, Google Drive, or Microsoft OneDrive cloud storage environment with Code42, Code42 detects the file events and file sharing that takes place in that environment and displays those details throughout Incydr for further investigation.
- File events: Code42 detects activity when users add, edit, copy or move, and remove or delete files stored in drives in your cloud storage environment.
- File sharing: 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.
This article defines the file events and file sharing activity that Code42 detects in a monitored cloud storage environment and describes the terms used throughout Incydr to display information about that activity.
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 the file event metadata.
| 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 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 a file's sharing permissions for this event. You can also click View sharing or View and manage sharing under Share type to view a file's full list of 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 the file event metadata.
Types of sharing
Because Box, Google Drive, and OneDrive use different terminology for sharing permissions in these environments, this terminology has been normalized in the file event metadata 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 file events. Additionally, the file event metadata 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 the file event metadata
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 the file event metadata 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.