Unusual Data Activity
Unusual Data Activity (UDA) for VMware is under early access and is available for limited customers.
Introduction
Suspicious data modification on a resource is called Unusual Data Activity (UDA). A user or malicious software can make such changes. For example, if a resource in your organization is under attack, the malicious software on the resource can start modifying and deleting files present in the resource. A resource is a device or server where data is stored.
- Unusual Data Activity displays insights about the data protected only for the following resources:
- Endpoints,
- NAS, and
- File Servers (Windows/Linux)
- VMware (Windows and Linux-64-bit)
- Data is displayed for up to the last 30 days.
When such a potential threat manipulates the data on a resource, it is suspicious in nature and is unlike how the resource owner works with data on that resource. Since anomalies of this type often indicate issues that require attention, Druva flags any such anomalous behavior in a resource and generates an alert.
Prerequisites for VMware UDA
If you are using UDA for virtual machines, ensure that the following prerequisites are met:
- VMware tools are installed and enabled on the virtual machine. For more information, see Install and Upgrade VMware tools.
- Keep the Guest OS credentials handy as you need to provide these details
- For Windows virtual machines: The user credentials provided must have administrator privileges or access rights
- For Linux virtual machines: The user credentials provided must have root privileges or access rights. For more information, see Manage credentials for VMware servers.
- The proxy version must be 6.3.0_259971 and above
- For Windows virtual machines: Enable USN journal for each drive with enough storage
- For Linux virtual machines: The iNotify watches maximum limit value must be more than the number of directories on the virtual machine
- For Linux virtual machines: Any one of these file system types should be present on the virtual machine - ‘xfs’ , ‘ext4’, ‘ext3’
For more information about the software requirements for VMware, see the Support matrix for VMware.
Support matrix for VMware UDA
The following are the supported windows versions for VMware UDA:
- Windows 10 (64-bit)
- Windows Server 2012 (64-bit)
- Windows Server 2016 (64-bit)
- Windows Server 2019 (64-bit)
The following are the supported Linux (64-bit) versions for VMware UDA:
- Red Hat Enterprise Linux (RHEL) 7.0 , 7.1, 7.2, 7.3, 7.4, 7.5
- CentOS 7.0 , 7.1, 7.2, 7.3, 7.4, 7.5
- Ubuntu 16.04, 18.04
Things to Consider
Following are a few limitations that you should know before using UDA for VMware:
Error: UDA scan fails with the following error: Invalid pid for Guest VM execution.
Description: This error is observed in the following scenarios:
- The glibc library version of the guest virtual machine is lower than 2.14
- The default SELinux restriction enforced by Red Hat. This is specifically observed for the SELinux policy version- selinux-policy-3.13.1-268.el7_9.2.noarch
Workaround: To resolve this issue, do the following:
- Upgrade the glibc library version of the guest virtual machine to 2.14 or above
- To bypass the SELinux restriction enforced by Red Hat, perform the following steps:
- Run the following command to check the SELinux status : # sestatus
- Set SELinux policy to permissive using # setenforce 0 command
- To persist enforcement policy, update selinux config file using # sudo vi /etc/sysconfig/selinux command
- Change the SELINUX=enforcing directive to SELINUX=disabled and then reboot the guest virtual machine
For more information, see Red Hat documentation.
How does Druva detect UDA
Druva’s automated intelligence analyzes and monitors the data activity trend for a given resource, and after a sufficient sample size, it builds the anomaly baseline. An alert is automatically generated and reported in case of any anomalous activity.
The following graphic provides an overview of the enhanced Unusual Data Activity:
Step 1 Learning period: In this step, Druva performs a data backup pattern analysis. See Data backup pattern analysis period.
Step 2 UDA detection process: In this step, Druva performs encryption checks on the backed-up files to detect anomalous file actions such as create, update, and delete.
Step 3: Generate and send a UDA alert: If any data anomalous activity is detected, a UDA alert is sent.
Following are the algorithm input parameters that Druva requires and uses to analyze the data activity trend and generate alerts in case of any suspicious data activity:
-
Data backup pattern analysis period for resources - Endpoints, File Server, NAS, and VMware: Displayed in Days or Snapshots
-
Number of files in a snapshot: A minimum number of files required within a snapshot to initiate UDA learning and scanning.
If the total number of files in a snapshot is less than the minimum number of files, then that snapshot is not scanned for UDA detection.
-
Deviation in the files from the baseline and total files in a snapshot: Percentage deviation threshold compared to the baseline and total files in a snapshot required to qualify as anomalous data.
Recommended UDA settings
Following are the recommended UDA settings for Druva’s analysis period to start encryption checks for a resource and generating UDA alerts.
We recommend that you keep the default - Recommended UDA Settings if you are not sure about the data backup pattern of your organization.
Data backup pattern analysis period for resources
-
30 days (For Endpoints): The default and recommended setting for Endpoints data backup pattern analysis. The UDA detection for Endpoints will start only if data has been successfully backed for the past 30 days. The permissible settings for days or snapshots are between 2 and 45.
-
20 snapshots (For File Server/NAS/VMware): The default and recommended setting for File Server/NAS/VMware data backup pattern analysis. The UDA detection for File Server/NAS/VMware will start only if there are 20 snapshots created after a successful backup. The permissible settings for days or snapshots are between 2 and 45.
-
100 or more files in a snapshot: The default and recommended setting for the minimum required files in a snapshot of a resource to initiate UDA detection for resources - Endpoints, File Server, NAS, and VMware. The permissible setting for a minimum count of files is between 20 and 500.
-
75% of baseline in the snapshot: The default and recommended maximum setting for the file actions (Create, Update, and Delete) in a snapshot for a resource to generate a UDA alert. UDA alert is generated if the deviation is observed beyond the set baseline value. The permissible setting for baseline is between 50 and 99%.
-
% of the total files in a snapshot: The default and recommended setting for the minimum change in the count of files out of the total files in a snapshot. The permissible setting for a minimum change in the count of files is between 5 and 99%.
You can use the UDA Settings > Edit option to customize and update the UDA configuration settings as per your organizational requirements and if you are aware of the data backup patterns.
If you have selected snapshots as your data backup pattern learning period criteria, ensure that the learning duration is completed within 45 days.
The following table explains the UDA behavior for Endpoints and File Server/NAS/VMware resources
Example
Scenario: UDA is enabled for a device with the following UDA settings with total 147 files.
Backup Pattern learning period |
Number of files required in a snapshot for UDA detection |
Baseline - Maximum Deviation |
Minimum percent of total file change |
05 snapshots |
10 |
50% |
20% |
The following example explains the UDA behavior using the UDA settings mentioned in the table above.
Snapshot |
Created |
Updated |
Deleted |
Total files |
Baseline calculation for Create, Update, and Delete = Maximum files in learning duration* (Maximum deviation +100/100) |
---|---|---|---|---|---|
1st |
3 |
0 |
0 |
147 + 3= 150 |
Create: Maximum (3) * (50+100)/100 = 3 * 1.5 = 4.5. Update: Maximum (0) * (50+100)/100 = 0 * 1.5 = 0. Update: Maximum (0) * (50+100)/100 = 0 * 1.5 = 0. |
2nd |
10 |
3 |
2 |
158 |
Create: Maximum (3,10) * (50+100)/100 = 10 * 1.5 = 15. Update: Maximum (0,3) * (50+100)/100 = 3*1.5 = 4.5 Delete: Maximum (0,2)* (50+100)/100 = 2*1.5 = 3 |
3rd |
15 |
3 |
4 |
170 |
Create: Maximum (3, 10, 15) * (50+100)/100 = 15 * 1.5 = 22.5 Update: Maximum (0,3,3) * (50+100)/100 = 3*1.5 = 4.5 Delete: Maximum (0,2,4)* (50+100)/100 = 4*1.5 = 6 |
4th |
12 |
5 |
5 |
177 |
Create: Maximum (3, 10, 15, 12) * (50+100)/100 = 15 * 1.5 = 22.5 Update: Maximum (0,3,3,5) * (50+100)/100 = 5*1.5 = 7.5 Delete: Maximum (0,2,4,5)* (50+100)/100 = 5*1.5 = 7.5 |
5th |
0 |
2 |
0 |
177 |
Create: Maximum (3,10,15,12, 0) * (50+100)/100 = 15 * 1.5 = 22.5 Update: Maximum (0,3,3,5,2) * (50+100)/100 = 5*1.5 = 7.5 Delete: Maximum (0,2,4,5,0)* (50+100)/100 = 5*1.5 = 7.5 |
Learning duration is complete - 05 Snapshots. UDA detection starts. UDA alert is generated if:
In the 6th snapshot: Let’s assume you add 20, update 8, and delete 2 files. So, now the total file count is 195. The total number of files is greater than the minimum required files so this snapshot will be scanned. As the created and deleted files are less than their respective baseline count, no anomaly is detected, and no UDA alert is generated for this action. However, the updated files are more than the baseline count, and hence UDA alert is generated for this action. Also, the baseline is updated because of the changes in the snapshot count. |
Administrators can take action based on the security policies of the organization to identify and isolate a possible threat and prevent additional losses.
Anomaly detection kicks in only after the backup job is complete and a snapshot is created. For incomplete backup jobs or interrupted backup jobs, no anomalous behavior is tracked.
View UDA alerts
Note: In the case of deleted resources (devices and backupsets) you cannot view the alerts for those resources. However, you can retrieve the deleted resources and view their alerts with the Rollback Action option.
Log in to Druva Console and go to Cyber Resilience > Security Events > Overview. The Unusual Data Activity Alerts card displays the number of active alerts in the defined time period.
Being notified about the resources showing unusual data activity can help you identify a potential threat in your environment such as a ransomware attack or a compromised user. Click the card to view details of the generated alerts.
The details of the generated alert contain the following information:
- Resource Name: The name of the resource for which the alert was generated. Click to view the details of the alerts generated for this resource.
- User Name: The name of the user associated with the device. This field is displayed only for Endpoints.
- Server Name: The name of the server associated with the backupset. This field is displayed only for Servers.
- Virtual Machine Name: The name of the virtual machine. This field is displayed only for Virtual Machines.
- VCentre/ESXi hosts: The details of VCentre/ESXi hosts. This field is displayed only for Virtual Machines.
- Affected Snapshot: The date and time stamp of the snapshot that was affected.
- Alert Type: There can be the following alert types:
- Creation: Too many files created in a short span.
- Modification: A large number of files edited or modified.
- Deletion: Several files deleted from the snapshot.
- Encryption: Files encrypted and are inaccessible.
- #Impacted Files: The number of files in the affected snapshot. If there are multiple types of unusual behavior in the snapshot, there is an info icon beside the number that provides details of the unusual activity.
- Status: There can be the following two statuses:
- Active: Denotes that no action has been taken on the alert.
- Resolved: Denotes that the alert has been looked into and the necessary actions were taken.
You can also download the logs for a particular alert and use it for further inspection.
Click the name of the resource to view the details of the resource and the alerts generated for that resource. The following screenshot displays Summary card for Endpoints.
The Data Activity Trend is a graphical representation of data backed up in the resource by snapshots.
Hover over the graph to view the following details of Unusual Data Activity for files:
-
Type of snapshots represented by different color codes:
-
Unscanned Snapshots
: Indicates either of the following
-
Learning period is in progress for the data backup pattern analysis
-
Snapshot does not comply with the minimum files required parameter set
-
-
Scanned Snapshots
: Indicates learning period and UDA detection is complete, and no data anomaly is detected. Snapshots are safe.
-
Impacted Snapshots
: Indicates learning period and UDA detection is complete. Data anomaly is detected within snapshots, and a UDA alert is generated for you to take action.
-
Quarantined Snapshots
: Indicates quarantined snapshots and needs further investigation by the security team.
-
-
Snapshot Size: The size of the snapshot
-
#Files: Number of files included in the snapshot
-
File Activity: The action performed on the file - Created, Updated, Deleted, and Encrypted
-
Snapshot: The snapshot count for each file activity - Created, Updated, Deleted, and Encrypted
-
Baseline: This value is generated dynamically from the list of snapshots based on the learning duration.
Note: Baseline values are not applicable for Encrypted files.
-
Deviation: The change of anomaly observed with reference to the baseline value. The deviation could be a positive or negative number and is displayed in percentage.
Note: Deviation is not applicable for Encrypted files.
Take action on an alert
For any unusual data activity alert, you can do any of the following:
- Ignore the alert: If you deem any alert as a false positive, click the resource name and select the false positive alert. Click Ignore to resolve the alert.
- Quarantine the resource: Select an alert and click Quarantine Resource to stop the ransomware from spreading further. Before you quarantine, see Know the impact of quarantining to learn more about the effects of quarantining the resource. To learn about the options to quarantine a resource, see Quarantine Response.
- You can also download the logs for a particular alert and use it for further inspection.
After you have taken an action, the status of the alert changes to Resolved.