Administration Guides

Best Practice for Tuning Ransomware Defender

Home


Overview

These sections cover guidelines on how to decide if whitelist of a detection or flag as false positive is the best option.

Definitions:

  1. Snapshot Critical path (Release 2.5.7.2 >) - New feature for customers using everyone full control on SMB shares to disable share snapshots per SMB share when ACL security is used.      This check box enables or disables share level snapshots .  This feature is designed to be used with critical path check box and entering paths to create snapshots each time a user detection occurs only the critical paths will have snapshots created.
    1. NOTE:  Critical path and share snapshots can both be enabled.   This allows application data ie. a critical path to be snapshotted when a user detection occurs.   NOTE:  snapshots are only created on SMB shares the user has access to via AD groups.   This allows other critical paths to get a snapshot created even when the user does not have access to this critical path.
    2.  
  2. Snapshot Quota Limit (Release 2.5.7.2 >) -  If everyone full control SMB shares are used or many detections occur in a short period of time a lot of snapshots can be created.  This feature will allow setting a limit to the number of snapshots that can be created.    Once snapshots expiry, it will allow more snapshots to be created up to the quota limit.     The quota can be changed to a different value.  The default is 1000 snapshots.
  3. Monitor Mode Lists (Release 2.5.7 >) - Using monitor mode lists allows path , user or IP address detection and alerting with lockout actions.   This should be done for any application where lockout would not be the desired action but alerting and snapshots are needed to protect the data created by the application.    Learn how to configure Monitor mode lists here.
    1. Whitelist option - Using the whitelist option for path, user or ip address will ignore any detections for any of these configured white list entries.  This should be used for data that does not require any monitoring or protection and raising alerts would generate too many false positives.  Learn how to configure whitelist here.
  4. Flag As False Positive Option - This applies custom detection rules for the user listed in an event.  This option will not ignore future detections by the same user and will allow all detection methods to detect, lockout and snapshot.  This should always be used to tune settings for any detection.  Learn how to manage flag as false positive here.
  5. Allowed Extensions Option - This removes a file extension from the banned list of well known extensions.  See the list of extensions published here.   This option means the file extension used by the user listed in the event is on the banned list.  You should review the extension and confirm this is a legitimate extension used by an application in your environment.   Once you have confirmed this is a safe extension you and remove it from the banned list following the CLI guide example here.       Learn how to manage banned file types here.
    1. Once a file extension is on the allowed list all future detections by Any user will no longer trigger a detection.
    2. NOTE:  The files with an allowed extension are still protected by user behavior detection, this does not reduce protection of the file system data.  It will only disable extension detection for this application.  


Best Practise

  1. Always apply flag as false positive as the first action on any new event after you have reviewed the detection and determined this is not actual Ransomware,  then wait to see if any future detections occur and repeat the flag as false positive steps again.
    1. If you have flagged a user detection event 3 separate times as flag as false positive, then we recommend to monitor mode list this user, see next section.
    2.  See guide here on how to flag as false positive.
    3. NOTE: Always use flag as false positive for user event detections avoid a whitelist for actual end users.
  2. Monitor only settings lists  should be used for server based applications versus users.   Server applications that modify the file system in a manor that is detected as Ransomware should have the server based application data added to the monitor mode list.
    1. Use a user based monitor list for the service account used by the application  Or use a source IP of the server IP address.  This offers the best option to allow the data in the file system to be protected but assumes the server itself will be monitored for any Ransomware behavior in the file system.
    2. See the guide on how to configure monitor mode list here.
  3. Ignore list -  Only use this list for data that does not require any protection. Temporary data that can be recreated that is tripping detections should be added to the ignore list.  Use a path based ignore list at the highest level of the file system.
    1. See the guide on how to configure ignore lists here.
© Superna Inc