Active Defense Active Defense is the BrickStor SP feature that detects ransomware attacks, malware activity, and other types of unusual activity on file systems in real time. When a Rule is triggered by suspicious activity, an Incident is created. This will trigger an alert, as well as initiate any of several actions such as blocking the user or IP address from which the attack originates. The creation of an Incident also causes Data Protection to create a point-in-time read-only snapshot of the affected file system to aid in isolation and recovery of affected files. Once an Incident is generated, an administrator may acknowledge it and remove any blocks that were put in place. Active Defense is managed using the Security Incidents screen of BrickStor SP Manager. Security Incident Display and Workflows To show Security Incidents: In BrickStor SP Manager, navigate to the General tab on the managed appliance. Click Security Incidents near the bottom of the Details pane. Incidents will be listed in the Security Incidents section with information including the type of incident, user, endpoint IP address, and timestamp. Use filters to sort the incidents by date/time. Selecting the Closed checkbox will show incidents that have been closed. Selecting an incident will show additional information and buttons to acknowledge or remediate the incident and provide actions to add watchers, notes, and more. Incident Details Type - type of incident. Score - severity score 0-10 (0-1.0, with 1.0 being absolutely confident). User - user login which triggered the incident. IP - user endpoint incident origination. Created - incident creation date and time. Acknowledged - which administrator acknowledged the incident and when (date/time). Closed - which administrator remediated the incident and when (date/time). Actions The Actions section displays the actions that were taken in reaction to the incident. The status balloon next to each action indicates the action’s status. Green corresponds to the action currently being enforced. Grey indicates the action has been lifted by the system administrator. The Lift button allow a system administrator to remediate the incident by Lifting or unblocking the restrictions created by the incident. Block Host - client endpoint IP address is blocked from accessing the shares. Block User - authenticated user login is blocked from accessing the shares. Hold Snapshots - related snapshots are held and their expiration time is extended. Prevent Auto Reapply - This drop-down allows the administrator to choose to create a time-limited exception for the user account, IP, and specific incident type. Datasets This section will show all datasets affected by the selected incident along with each dataset’s Activity and Snaps buttons. Clicking the Activity button will open the User Behavior management screen filtering view to show activity related to this dataset. Snaps will open the Snapshot management screen of Data Protection. Watchers Watchers can be added to the incident in order to receive emails about the attack. This is done by selecting the Add icon next to Watchers and adding the email address of the user. Lift or reapply the actions of blocking the user, IP, and holding snaps by selecting Lift and checking off which action to lift/reapply. Notes The Notes section will list any notes added to the incident. Notes can be added, edited or deleted at any point until an incident is Closed. It is also possible to add a note while adding watchers. To append a note: Click the plus (+) icon next to Notes Enter message text Click the Add Note button to save it Recent Changes The Recent Changes section shows audit log events associated with this incident starting from when it was first detected. Events The Events section lists all events triggered by the user activity for this incident. Manual Incident Creation It is possible to manually create incidents and to apply actions to or alert on the incident. Press the Create Incident button to open a the incident details menu. Update the fields for the incident category, name, assigned threat level, involved user, dataset, host, and any notes regarding the incident. Watchers and actions may be assigned to the incident to block the user or host from access and alert on any occurrences of such access being attempted. Manual Rule Creation You have the option to create a rule in the incidents tab. Manual rule creation allows you to add the category of the incident, score, user, host, datasets, watchers, and apply any actions as well as create a custom action. It also allows you to define the rule type (continue processing rules, stop processing rules, or do not open incident). There is also the option of adding an expiration date on the rule. You can do this by clicking rules in the upper right hand corner of the incidents tab, clicking edit at the bottom of the Rules tab, and then clicking Add. The user has the option to access the security incident rules through the system tab at the appliance level. Assessors and Rules Assessors and rules are used by Active Defense to constantly analyze the activity of the system or datasets. Any activity that matches the criteria set forth in each rule or assessor causes an Incident to be created with predetermined actions and alerts activated. The list of Assessors and Rules can be viewed by clicking the Rules button on the Security Incidents screen. Assessors Assessors include the following: Ransomware Protection Malware Protection Unusually high read activity Unusually high write activity Unusually high delete activity Administrator write activity Administrator delete activity Assessors activity on the system. The rules of these assessors are explained further in the following sections. Ransomware & Malware Protection BrickStor SP, when detecting a potential ransomware or malware attack will immediately ban the suspected agent, and place recent snapshots on hold so that they may be reinstated if needed. Moreover, BrickStor SP will provide detailed information of the agent, time of attack, and threatened files. Insider Threat The Excessive File Access feature is a part of BrickStor SP’s Active Defense capabilities, and has the ability to detect various excessive file operations including reads, writes and delete operations. The option to enable Excessive File Access is on the sharing tab for a dataset and is configurable per dataset. Enabling the Excessive File Access option will open a new dialogue box that allows the configuration for how many file operations to track per minute. For each of the three file operation trackers, there are options to Notify After and Block After. Once the Notify After threshold for a certain file operation has been reached, an incident will be created which can be viewed on the Security Incidents screen. This will display the type of incident that has occurred, the user, the host IP for where the activity came from, and the dataset that was affected. After the file threshold for Block After has been reached, the block and hold snapshot action have been applied for that specific incident. Auto-Reapply The auto-reapply feature allows the the lifting of any or all actions after an incident has occurred. This will prevent those actions from being reapplied for a specific amount of time. This allows the performance of normal operations after an incident without being blocked out of the share for a certain amount of time. This will authorize normal actions to be taken shortly after an incident without being flagged. Excessive File Access Assessors The excessive file access assessors can detect various file operations that stand out in quanitity over a given timespan given typical access patterns. The actions in these assessents include file read, write, and delete operations. Enabling any of the excessive file access assessors can be done in the sharing tab on each dataset. These assessors are configurable on a per-dataset basis. Enabling the Excessive File Access option will open a new dialog box that allows you to configure how many file operations you want to track per minute. For each of the three file operation trackers, there are options for Notify after and Block after. Once the Notify after threshold for a certain file operation has been reached, an incident will be created which can be viewed on the Security Incidents screen. From here you can see the type of incident, the user and the host IP from which the activity originated and the dataset that was affected. After the file threshold for the Block after has been reached you will see the block and hold snapshot actions have been applied for that specific incident. Administrator Access Assessors Administrator access assessors detect when any administrator, domain administrator, enterprise administrator or account operator initiates an operation against a file. The rules for the Admin Access incidents are default rules and the only action applied will be the Hold Snapshots action when this incident is triggered. Once an Admin Access incident is triggered you will see the user account name and the IP address of the device they were using at the top of the screen. You will also see the affected dataset(s) listed, as well as the number of affected files and the Show Files option to recover any files if necessary. Admin Access Incidents The Active Defense feature also includes an Administrator Access assessor that will detect when any Administrator, Domain Admin, Enterprise Admin or Account Operator does an operation against a file. The rules for the Admin Access incidents are default rules and the only action applied will be the Hold Snapshots action when this incident is triggered. Once an Admin Access incident is triggered, the user account name and the IP address of the device they were using at the top of the screen. The system will also display the affected dataset(s), as well as the number of affected files. Select the Show Files option to recover any files if necessary. Threat Level When an incident occurs, threat level is listed in the events section in the incidents tab. * Threat level indicates the attack’s severity via a numbered severity scale (0-10, with 10 being a critical threat), multiplied by the system’s confidence in the attack’s validity (0-1.0, with 1.0 being absolutely confident). File Recovery After an incident occurs, the administrator has the ability to see which files have been affected and can decide which ones should be recovered or deleted. Click show files to see which files have been affected. When accessing the affected share, the administrator is also able to see which files have been affected and the ransom note if one has been added. In this case, each file has a WNCRY extension added to it. Click Restore File to recover the original file before it was encrypted and click Delete File to delete the encrypted file. If a file already exists with the same file name within the share, then there is an option to overwrite that file, rename it to the existing time stamp, or rename it with the current time stamp. After restoring the original file and deleting the encrypted file, the share should now only have the recovered version. Quarantining a File There is also an option to quarantine a file in case a file was unable to be recovered correctly. To quarantine a file: Click quarantine and it will go into the quarantine dataset located under the global dataset. Once in the quarantine dataset, go into the Sharing tab and enable SMB share. Hover over the Connect Using and click Go to access that share. Within that share, the file the administrator has chosen to recover can be accessed. This allows the administrator to inspect files before deciding to delete them. Bulk Recovery Once an incident has been created, the BrickStor SP Manager will display a breakdown of affected files. This is located by clicking the incident, and navigating to the Impacted Files and Recommendations section. In this section, all affected files will be counted. To see the affected files in further detail, click View All. Immediately below, the affected files are sectioned by whether files were added or removed. If the incident involved unrecognized access, click the Other section to view affected files. Click View All to view the files that were impacted by the incident, the following screen will present: A list of incident-affected files will be displayed. The left-side panel provides options to select/filter through files and control the parameters of the bulk recovery feature. Bulk Recovery Visual Feedback Files before and after the recovery process are color-coded to show the progress of the recovery process. At the Incident Screen, the file breakdown will show a file count of recovered/un-recovered files: Recovered files will be displayed in green text. Removed files will be displayed in red text. Unresolved files will be displayed in white text. At the Bulk Recovery screen: Files that have been recovered will be shown with a green background. Files that are unresolved will show with a dark blue background. Files that have been removed will show with a red background. Filters The filters allow for management of affected files when deciding to recover or remove them based on the type of incident created: The following options may be selected: Any - List all impacted files. Restore - List only files with restore recommendation. Remove - List only files with remove recommendation. Other - List only impacted files without a recovery action (ex. files from an Admin Read incident). Restore Version Modified Eligibility The Restore Version Modified Eligibility textbox configures the required confidence that the snapshot just prior to the incident is the best snapshot to recovery from, and thus is a good candidate for bulk recovery. Confidence is configured by adjusting the duration between when the previous file version (before the incident) was last modified and when the file was first impacted by the incident. By increasing the configured duration, a higher confidence requirement is set that the file version just prior to the incident is the best version to recover from. For example, there is a high confidence that the file version just prior to the incident is the best recovery version for a file that had not been modified for an hour, up until the file was affected by the incident. On the other hand, there is a lower confidence that a file version just prior to the incident is the best version to recover from for a file that was regularly modified every second prior to the incident. In the case where a file was modified in close proximity to being affected by the incident, manually choosing the snapshot to recover from is the best option. Within the supplied text box, a default time of fifteen minutes will be entered. This value dictates that any file that was edited within fifteen minutes of an incident will be ineligible for bulk recovery, and must be recovered or removed manually. Beneath the modifiable eligibility, information regarding the total amount of eligible and not eligible are displayed numerically. The buttons below provide an administrator the ability Select/Unselect Eligible files when creating a recovery plan. Run Recovery Plan To select files for recovery, manually click checkboxes for the chosen files, or click Select Eligible to select all files matching the filters. Click Run Recovery Plan once desired files are selected for recovery. A prompt will present ensuring that the Recovery Plan has been run intentionally: Click Yes to run the Recovery Plan. Click No to cancel the Recovery Plan and return to the previous screen. Clicking Yes will initiate the Bulk Recovery of the eligible files. A progress wheel and a numeric description of the recovery progress will present. Manual File Recovery Files that prior to the incident were last modified more recently than the configured Restore Version Modified Eligibility will not be eligible for the current bulk recovery plan. To recover those ineligible files, the 'restore version modified eligibility' can be lowered in the next bulk recovery plan, or manual recovery can be used to manually choose the desired recovery version. To see a detailed view of the ineligible files, and to initiate recovery or removal of the affected files, click Manual File Recovery The following screen shows a list of ineligible files, as well as a description of their data and the date/time of the file’s last edit. To augment the list of files, a selection of filters is provided at the top of the screen. The options provided are as follows: Type - Change the list to display any affected file type. Search - Search for a specific file. Snapshot Limit - Augment the amount of snapshots shown within the list. Hash files - Select to show/hide Hash Files Show Resolved - Select to show/hide resolved files. Bulk Recovery - Select to return to the Bulk Recovery screen. To initiate a recovery of an affected ineligible file, navigate to the desired file within the list provided. A selection of file versions will be listed within each respective file’s description. This shows the date/time that the file was edited for each version, as well as a counter for when the file was edited in relation to the incident’s creation. After deciding which file version to select, click Restore to initiate the Manual Recovery of the file. A prompt will display that directs where the file is to be recovered to. Select the appropriate option, then click Restore. If a file is recovered, but remains encrypted or damaged it is possible to recover an older version by following the steps above, and selecting an older version of the file. The option to Overwrite should be selected to replace the file with a version that is usable.