Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Threat Detection and Severity Settings

Overview​

Ransomware Defender monitors file system activity in real time and uses a set of independent threat detectors to identify patterns consistent with ransomware and data destruction. When enough detectors fire with enough frequency, the system raises a security event and escalates it through severity levels — each with a different automated response.

This section explains what the detectors are, how severity levels work, how to configure thresholds and signal strength, and how enforcement modes determine what action the system takes.

Threat detector types​

The system uses multiple independent threat detectors that run in parallel against the stream of audit events from your PowerScale or ECS cluster. Each detector watches for a different behavioral pattern. When a detector fires, it contributes to the Signal Strength of that user's security event.

For the authoritative numbered reference of every detection type (TD1–TD18) and its category, see Detection Types.

Detectors fall into three broad categories:

Behavioral detectors​

These detectors identify activity patterns that are statistically consistent with ransomware or destructive behavior, regardless of file extension.

DetectorWhat it looks for
Data Creation and DeletionUser creates new files while deleting originals — the classic encrypt-and-replace pattern.
Data EncryptionNew files created with an encryption-associated extension while originals are removed.
Data RenamingBulk file reads followed by mass renames — consistent with ransomware staging.
Data OverwriteFiles are read and then overwritten with new content — consistent with in-place encryption.
Multi-Extension File ModificationFiles are renamed to more than one new extension in a single session.
Mass DeleteMultiple files or objects deleted from a single location in bulk. Requires an Active Auditor trigger to be configured.
Data Loss PreventionA user's read volume from a monitored path has exceeded the configured DLP threshold. Requires an Active Auditor DLP trigger to be configured.

Extension-based detector​

DetectorWhat it looks for
Suspicious ExtensionFile operations (read, create, rename, or other) involving extensions on the Suspicious Extensions list — for example .blacksuit, .locky, .zzz. The list is maintained by Superna and updated automatically. Supported on both PowerScale and ECS.

Honeypot detector​

DetectorWhat it looks for
Honeypot ActivityAny interaction with honeypot files (or, on ECS, bait objects) placed as tripwires across the file system. Because honeypot files have no legitimate business purpose, any access is significant regardless of other activity. Supported on both PowerScale and ECS. See Honeypot Tripwire Configuration to place these files.

Security Guard Simulated Attack​

DetectorWhat it looks for
Security Guard Simulated AttackActivity generated by Security Guard during automated testing. This detector can be safely ignored during incident response — it confirms the health check system is functioning, not a real attack. Supported on both PowerScale and ECS. See Health Check — Security Guard.

ECS object storage detectors​

Dell ECS object storage environments add the following object-aware detectors, in addition to the shared Suspicious Extension, Honeypot, and Security Guard Simulated Attack detectors documented above:

DetectorWhat it looks for
Data Encryption (ECS)Encrypted object uploaded to a bucket while previous versions are deleted.
Data Overwrite (ECS)Objects read and overwritten with new content.
Encryption Key Change (ECS)Objects copied with a new encryption key — consistent with ransomware re-encryption.
Data Deletion (ECS)Bulk deletion of objects or buckets.

All detectors are enabled by default. Individual detectors can be disabled in Detection Controls → Settings → Threat Detectors if they generate sustained false positives that cannot be addressed through the Ignored List or Learned Thresholds. Disable detectors only when there is a specific, documented reason — each disabled detector is a gap in coverage.

Each detector can also be set to a Monitor only state instead of being disabled. In Monitor only state a detector still alerts and takes a snapshot, but it does not lock out the user. A disabled detector no longer protects the file system. Consult Superna Support before changing the state of any detector, because a misconfiguration can disable protection of your file system, and disabling all detectors turns off detection for every severity — use it only as a temporary measure.

Signal Strength​

Signal Strength is a numerical score that accumulates for a user as threat detectors fire. It is the primary measure used to determine which severity level an event reaches.

  • Each time a detector fires, it adds to the user's Signal Strength score.

  • The score reflects both how many detectors fired and how many times they fired within the measurement interval.

  • Signal Strength is displayed on the Threat Detections page for every active event, with a visual bar and a number out of 100.

  • Clicking the Signal Strength bar in the event detail panel shows the breakdown of which detectors contributed and their individual share. Single Vector vs. Dual Vector: Signal Strength thresholds are split into two tracks depending on how many independent detector types have fired.

  • Single Vector — only one type of detector has fired (for example, only Data Encryption). A higher raw Signal Strength is required to escalate to Major or Critical, because a single detector firing could have a legitimate explanation — a backup application, a file conversion tool, or a migration script.

  • Dual Vector — two or more independent detector types have fired simultaneously (for example, both Data Encryption and Suspicious Extension). The threshold required to escalate to the same severity level is lower. Two unrelated detectors firing at the same time is a much stronger indicator of a real attack — it is statistically unlikely that two distinct behavioral patterns consistent with ransomware would both occur coincidentally from a legitimate application. In practice, this means a Dual Vector event at a lower raw Signal Strength score can trigger a Major or Critical response faster than a Single Vector event would. This is intentional: when multiple independent signals corroborate each other, the system acts sooner.

The specific Signal Strength thresholds for each severity level and vector type are visible and configurable in Detection Controls → Settings → Advanced Severity Levels. Do not modify these values without consulting Superna Support.

Severity levels​

Security events are classified into three severity levels. The level determines what automated response the system takes and how urgently you need to act.

Warning​

Signal Strength threshold: Lowest of the three levels.

What happens:

  • The event appears on the Threat Detections page in Monitor state.
  • No lockout is applied automatically.
  • Snapshots are taken proactively on all shares the user can access.
  • A countdown timer starts. If no further suspicious activity occurs before the timer expires, the event auto-closes — as False Positive (with auto-learning applied) if Auto-Learn From Events is enabled, or as Unresolved if it's disabled. See Learning mode explained.
  • You are notified and can investigate manually.

What to do: Review the affected files and user. If the activity is legitimate, let the event auto-close or close it manually as False Positive. If it looks suspicious, escalate — use Take an Action → Lockout Now to apply a lockout without waiting for the event to reach Major or Critical.

The auto-close countdown defaults to 30 minutes and is configurable in Detection Controls → Settings → Response Settings → Event Severities → Warning → Event Expiry.

Major​

Signal Strength threshold: Mid-level. Reached when sustained or higher-intensity suspicious activity is detected.

What happens:

  • The event escalates to Delayed Lockout state.
  • A lockout countdown timer begins, defaulting to 4 hours. The duration is configurable in Detection Controls → Settings → Response Settings → Event Severities → Major → Event Expiry.
  • You have until the timer expires to investigate and either stop the lockout (if the activity is benign) or accelerate it (if you confirm it is malicious).
  • If the timer expires without intervention, the lockout is applied automatically.

What to do: Open the event immediately. Review the affected files, the user, and the Client IP. Contact the user if needed. Use Stop Lockout Timer to cancel the lockout if you confirm it is a false positive. Use Lockout Now to apply the lockout immediately if you confirm the threat.

If a specific user, Client IP, or path should never be locked out — a known backup service account, for example — add it to the Monitor Only list instead of handling each event manually. See Monitor Only list.

Critical​

Signal Strength threshold: Highest level. Reached when the system detects strong, continuous, or multi-vector ransomware activity.

What happens:

  • The event immediately transitions to Lockout state.
  • The user's SMB access is revoked across all accessible shares on all managed clusters with no grace period.
  • Snapshots are taken of all share paths the user had access to (subject to snapshot budget).
  • You are notified immediately.

What to do: Do not restore access until you have completed an investigation. Open the Investigate & Recover page, review the Items & Recovery and Activity Log tabs, and confirm what happened before using Restore User Access.

As with Major events, a user, Client IP, or path that should never be locked out can be added to the Monitor Only list to exclude it from automated lockout at any severity. See Monitor Only list.

Monitor mode vs. enforcement mode​

The Lockout Behavior and Learning setting in Detection Controls → Settings → Response Settings determines what the system does when events reach the Major or Critical threshold.

Three modes are available:

Monitor mode​

The system detects threats and raises events on the Threat Detections page, but does not apply any lockout automatically, regardless of severity. All events appear and accumulate Signal Strength, but no user access is ever revoked by the system. In Monitor mode, events are only ever raised at Warning severity.

Use Monitor mode during initial deployment to observe what the system would do with your environment's normal activity before committing to automated lockouts. Running in Monitor mode for one to two weeks before switching to Enforcement is strongly recommended for new deployments.

Tip: If you forward events to a SIEM or webhook receiver (see Webhook Configuration), filter on Severity: WARNING and State: MONITOR to isolate Monitor-mode activity from events that actually triggered a lockout — useful for tuning thresholds without being paged for events the system never acted on.

Enforcement mode​

Events can reach Warning and Major severity. When the Major threshold is reached, a delayed lockout countdown begins. Administrators have the countdown window to intervene; if the timer expires without intervention, the lockout is applied.

This is the recommended operating mode for production environments once baseline tuning is complete.

Critical mode​

Events can reach Warning, Major, and Critical severity — this mode changes which severities can be raised, not what each severity does once raised. Each severity still behaves as described in Severity levels above: Warning applies no lockout and starts the auto-close countdown, Major starts the delayed-lockout countdown, and Critical applies an immediate lockout with no grace period.

Recommend this mode only where events are reviewed quickly, or where events reach a security team's SOAR/SIEM with a 24/7 team and a defined SLA — accepting the higher rate of disruption to legitimate users from false positives.

Configuring threat detection for ransomware defense​

To set up Ransomware Defender's response mode and protective snapshots for your environment:

  1. Navigate to Data Security → Threat Detections → Detection Controls → Settings → Response Settings.
  2. Locate the Lockout Behavior and Learning setting and choose Monitor, Enforcement, or Critical (see the mode descriptions above).
  3. Save the setting. The new mode applies to all subsequent events; events already in progress continue under the mode active when they were raised.
  4. Configure protective snapshots for the events this mode will generate — see Snapshot Settings to set the SMB/NFS protocols snapshotted, the snapshot quota, and any critical-path snapshot paths.
  5. Review individual threat detectors and disable only those generating sustained, documented false positives — see Threat detector types above.

Recommendation: Start in Monitor mode. Move to Enforcement mode after completing baseline observation and tuning. Reserve Critical mode for specific high-security segments of your environment if needed.

note

Enforcement mode is not required to protect the file system. All modes protect data all the time, because snapshots are taken in every mode. The mode only determines how you respond to detections.

Choosing a mode for your risk tolerance​

The target is fewer than 1 detection per day. The more sensitive the detection, the more likely a false positive becomes. Use the following best practices to choose a mode:

  • Use Monitor mode if you cannot assess threats 24/7.
  • Use Enforcement mode only if you have a 24/7 SOC, or if you can tolerate a user being locked out of the file system until an administrator can assess the threat.
  • Use learning until detections per day drop below 1, and use it again whenever you introduce a new application, so the system learns its behavior. See Learning mode explained.

The following table summarizes the response and business impact at each severity:

SeverityActionSnapshot protectionBusiness impact
WarningNo lockout. Email alert is sent.Snapshot applied to all shares the user can access.No impact on applications or user access to data.
MajorTimed lockout of the user. Email alert is sent.Snapshot applied to all shares the user can access.Business applications or servers that write data and are not on the Ignored List can be locked out, causing application downtime until access is restored. Recommendation: add them to the Ignored List.
CriticalImmediate lockout of the user. Email alert is sent.Snapshot applied to all shares the user can access.Application downtime until access is restored, with no wait time for an administrator to decide on an action. Recommendation: add them to the Ignored List, or disable Critical actions by using Enforcement mode.

Recommended settings by risk tolerance:

Risk toleranceRecommended settings
LowMonitor mode with email alerts.
MediumDo not use Critical mode (use Enforcement mode), so immediate lockouts are disabled. Set the Major lockout countdown (grace period) to a value that gives an administrator time to reach the event and decide whether the lockout should occur — for example, 60 minutes. Keep snapshots enabled.
Medium-HighUse Critical mode, so immediate lockouts are enabled. Set the Major lockout countdown to a value that gives an administrator time to decide whether the lockout should occur — for example, 60 minutes. Keep snapshots enabled.

With the Medium setting, files can be encrypted for up to the grace period, but a snapshot protects the file system at the point of detection, which accelerates recovery. The event lists all affected files so you can build a recovery list. With the Medium-High setting, users are locked out immediately, so the risk of a false-positive lockout is higher.

Eight methods protect the file system:

  1. User behavior-based detection, proven in independent third-party testing of live ransomware attacks.
  2. Dynamic real-time learning of behaviors.
  3. Honeypot tripwire.
  4. Crowd-sourced file extensions (more than 2,500, updated monthly).
  5. Slow attack detection.
  6. Burst attack detection.
  7. Automated escalation response.
  8. Inbound API from external detection engines (IDS, IPS, endpoint, XDR, SIEM).

When to move to Enforcement mode​

Review the detection metrics before switching from Monitor mode to Enforcement mode:

  • The target for enabling Enforcement mode is fewer than 1 signal event per day over the last 7 days.
  • Use the 30-day statistic to see whether the trend is going up or down compared to the last 7 days.
  • If the value is above 1 per day over the last 7 days, use learning to configure the settings automatically before enabling Enforcement mode.

Before onboarding a new application onto a cluster already running in Enforcement or Critical mode, see Planning New Application Workloads.

Threshold configuration and signal strength tuning​

The precise Signal Strength values, time intervals, and event upgrade criteria that determine when an event moves from Warning to Major to Critical are configured in Detection Controls → Settings → Advanced Severity Levels.

This section exposes:

  • Signal Strength — Single Vector: The raw score required at each severity level when only one detector type has fired.
  • Signal Strength — Dual Vector: The raw score required at each severity level when two or more detector types have fired.
  • Interval: The time window (in minutes) within which Signal Strength must accumulate.
  • Minimum User Behavior Duration: How long the suspicious behavior must persist before the severity is elevated.
  • Upgrade criteria: The number of events and affected files required to escalate between severity levels.

Do not modify these values without guidance from Superna Support. Incorrect configuration can cause missed detections, excessive false positives, or failure to trigger lockouts on real attacks. A Reset to Default button is available to restore factory values.

A lower Signal Strength threshold makes detection more sensitive. A larger number can avoid false positives, depending on the I/O patterns in your PowerScale environment. The Major grace period sets how long a Major event waits before the user named in the event is locked out. Set it to a value that gives an administrator time to review the event and decide whether the lockout should occur or be canceled.

Tuning thresholds when too many unwanted events are raised​

If the default thresholds are too sensitive and too many unwanted events are raised, you can increase the Signal Strength thresholds as follows, then save the changes:

  • Set the Warning Signal Strength threshold to 80.
  • Set the Major Signal Strength threshold to 83.
  • Set the Critical Signal Strength threshold to 100.

Rapid machine-to-machine malware spreading defense​

The upgrade criteria protect against a multi-user scenario, where malware affects many machines in a short period of time and spreads from machine to machine. The response escalates automatically based on the number of concurrent events:

  • Upgrade to Major (events) — Advances all Warning events to Major when the number of separate Warning events for different users matches or exceeds this value, even if no single event has crossed the Major Signal Strength threshold. Many warnings in a short period are treated as suspicious.
  • Upgrade to Critical (events) — Advances Major events to Critical when the number of separate Major events for different users matches or exceeds this value, even if no single event has crossed the Critical Signal Strength threshold. This locks out the users sooner as a proactive response.

For example:

  • If Upgrade to Major (events) is set to 8, 8 separate Warning events cause the response to be upgraded to Major, and a timed lockout starts.
  • If Upgrade to Critical (events) is set to 10, 10 separate Major events cause the response to be upgraded to Critical, and an immediate lockout is activated.

Best practice: set the Warning-to-Major value to a higher number, for example 5, and the Major-to-Critical value to a lower number, for example 8.

Disabling immediate lockouts and snapshots​

To disable immediate lockout and use only the Major timed lockout, choose Enforcement mode instead of Critical mode in Detection Controls → Settings → Response Settings → Lockout Behavior and Learning. This is recommended when the risk of locking out a user should be reviewed by an administrator through the timed lockout on Major events. For the change to take effect, archive all active events as resolved or unresolved before changing the mode.

Disabling the snapshot action for all detections is not recommended for normal operations, because snapshots are a critical part of the solution for data recovery. Consult Superna Support before disabling it. See Snapshot Settings.

For managing false positives without touching raw thresholds, use the tools described in Detection Controls and False Positive Management:

  • Learned Thresholds for per-user, per-path, or per-group sensitivity adjustments
  • Application Fingerprinting for automated suppression of known safe application behavior
  • Ignored List to exclude specific paths, users, or IPs from detection entirely
  • Monitor Only to observe without alerting

Active Auditor​

Active Auditor provides real-time auditing capabilities that let administrators define and respond to specific file activity behaviors across the cluster. Using prebuilt and custom triggers, you can monitor actions such as mass deletions, file accesses, and user activity patterns. Active Auditor triggers (Mass Delete, Data Loss Prevention, Custom Triggers) generate events that appear on the Threat Detections page alongside Ransomware Defender events and follow the same severity escalation model — the Signal Strength from Active Auditor detectors contributes to the same event for a given user.

Starting with version 2.15.0, Active Auditor supports integration with Cyber Recovery Manager.

Navigate to Data Security → Threat Detections → Detection Controls → Active Auditor in the left sidebar. Events generated by Active Auditor triggers appear on the Threat Detections page alongside Ransomware Defender events and follow the same severity, triage, and response workflow (see Threat Detection — Features).

note

Active Auditor is supported for SMB only. It does not apply to NFS.

This section covers the following features:

  • Mass Delete — Detect unusually high rates of file deletions.
  • Custom Real-time Audit Policy — Define complex rules using AND/OR logic.
  • Data Loss Prevention — Monitor users copying files from secured shares or paths.

Trigger list​

The Active Auditor tab shows one summary card per trigger type at the top (for example, Mass Delete and Data Loss Prevention), each showing a count of triggers of that type and a single toggle that enables or disables the entire category at once. The trigger list below shows each individual trigger's name, type, monitored path, configuration summary, its own on/off status toggle, and last-modified date.

caution

The category-level toggle on a summary card is separate from the per-trigger toggle in the list below it — disabling a category from its summary card disables every trigger of that type at once, regardless of each trigger's individual toggle state. A category card reading "disabled" is a common cause of "my triggers stopped firing" reports; check the summary cards first before troubleshooting individual triggers.

Use Search Triggers to filter by name. Use the filter icon to filter by type or status. To delete triggers in bulk, select checkboxes and click the trash icon.

Mass Delete​

The Mass Delete trigger is a prebuilt policy that detects unusually high rates of file deletions in a specified directory. Use it to identify risky behaviors such as accidental or intentional mass deletions that could lead to data loss or operational issues.

Configure a Mass Delete Response​

  1. Navigate to Data Security → Threat Detections → Detection Controls → Active Auditor.

  2. Click + Create Trigger, select Mass Delete, and click Next.

  3. Fill in the following fields:

    • Trigger Name — Enter a name for this trigger.
    • Path — Use the Cluster Directory Selector to choose the directory to monitor.
    • Files — Number of files that must be deleted to trigger the response. Pre-filled with a default of 1000 — this is a starting value, not just a recommendation; adjust higher if too many notifications are sent.
    • Interval — Define the time window for tracking events, pre-filled with a default of 1 minute:
      • Value — Enter a number (for example, 1).
      • Unit — Choose a time unit (for example, Minute(s)).

  4. Select Save to create the trigger, or Cancel to discard changes. The new trigger appears in the trigger list under Active Auditor — see Editing and managing existing triggers below to edit, delete, or disable it.

info

Snapshots created by Mass Delete and other Active Auditor triggers use the same snapshot budget as Ransomware Defender, and Active Auditor triggers ignore any user, source IP, or path already configured in the Ransomware Defender Ignore List. See Ignored List and Monitor Only list.

Custom Real-time Audit Policy​

The Custom Real-time Audit Policy feature enables you to define specific conditions using rule-based logic with AND/OR groupings. Use it to detect abnormal or unauthorized behaviors with precision.

Create or Edit a Custom Real-time Audit Policy​

  1. Navigate to Data Security → Threat Detections → Detection Controls → Active Auditor.

  2. Click + Create Trigger, select Custom Trigger, and click Next.

  3. Under Basic Configuration, fill in the following fields:

    • Name — Enter a descriptive name for the policy (for example, High File Access Alert).
    • Enabled — Select the checkbox to activate the policy.

  4. Select View/Edit Audit Criteria to open the rule builder and define conditions using AND/OR logic to match specific audit events.

    Available criteria include:

    • Directory — Monitor a specific folder path.
    • Full Path — Track activity for a specific file.
    • File Name or Extension — Focus on specific file types or names.
    • Event Type — Choose actions such as File Delete, Read, or Write.
    • User — Monitor actions by a specific user. Enter the username in DOMAIN\user format.
    • Cluster Name — Filter by originating cluster.
    • Source IP — Limit activity by IP address. Use CIDR notation. Any range except /32 is valid.

    Logic options:

    • Add Rule — Add a new condition.
    • Add Group — Nest multiple rules under AND/OR logic.
    • Delete — Remove individual rules or groups.

  5. After defining your rules, select Save to return to the configuration screen.

  6. Configure the following monitoring parameters:

    • Interval — Define the time window for tracking events:
      • Value — Enter a number (for example, 1).
      • Unit — Choose a time unit (for example, Minute(s)).
    • Threshold — Enter the number of matching events that must occur within the interval to trigger the policy (for example, 100).

  7. Select Save to create the trigger, or Cancel to discard changes. The new trigger appears in the trigger list under Active Auditor — see Editing and managing existing triggers below to edit, delete, or disable it.

Custom trigger reference​

  • Evaluation: The policies run on the ECA cluster in real time as events are processed. Custom triggers apply to SMB users only, not NFS client connections. The policy is sent to the ECA immediately when you save it.
  • Interval: The period over which the policy monitors events to decide whether the condition was met. It can be set from 1 to 60 minutes.
  • Threshold: The number of times the condition must be met within the interval to trip the policy. No alert is sent until it is met. Valid values are any number greater than 0. Tune it so the policy does not trip too easily, or lengthen the interval to monitor over a longer period. Threshold crossing uses predictive rate monitoring, which calculates the rate of detection to determine whether the policy will be true at the interval you set, so you do not need to work out a specific rate. The trigger window indicates whether a detection was predicted or actual.
  • Group by (advanced): By default, the policy is evaluated per user. User and path evaluates the policy per user and a single path, so a user and one path must meet the configured criteria. User and cluster trips the policy only when the user and a cluster match the criteria, unlike the default, where events for the user from any cluster are evaluated together.
  • Alerts: Alert emails and syslog messages contain the name of the trigger, which external tools can use.

Audit criteria and supported comparison options:

CriterionExampleSupported comparisons
Full Path (path with file name)/ifs/data/zone1/marketing/marketing-plan.docxequal, not equal, contains, doesn't contain, ends with, doesn't end with, begins with, doesn't begin with
Directory/ifs/data/zone1/marketingequal, not equal, contains, doesn't contain, ends with, doesn't end with, begins with, doesn't begin with
File Name (without regard to path)marketing-plan.docxequal, not equal, contains, doesn't contain, ends with, doesn't end with, begins with, doesn't begin with
Extensionpdf or docxequals, does not equal
Event TypeCreate, Read, Write, Delete, Renameequals
UserDOMAIN\user (uppercase domain name)equals, does not equal
ClusterCluster name the event came from. Use only when Active Auditor manages multiple clusters.equals, does not equal
Source IP192.168.1.0/24 for any host in the 255.255.255.0 subnetin, not in

As of release 2.5.8.2, directory delete, directory create, directory rename, login, and ACL change event types are also supported.

You can combine criteria with AND and OR, for example, a file name AND user X, or this directory OR user X. Use a group to combine several criteria under one AND or OR. With AND, all criteria in the group must be seen within the interval. With OR, any criterion in the group must be seen within the interval. You can also combine a group with individual criteria, using AND or OR within the group and between the group and the individual criteria.

Custom trigger examples​

  • Directory rename: To monitor a path and all folders beneath it for directory renames, create a custom trigger with an event type of directory rename (requires release 2.5.8.2 or later). Set the threshold to 1 or more to see all renames, or increase it to detect a burst of changes within the interval.
  • Directory or file ACL change: To be notified in real time when users change ACLs, create a custom trigger with an event type of ACL (file or directory). A directory ACL is recommended (requires release 2.5.8.2 or later). Set the threshold the same way.
  • Login: To monitor user login behavior with real-time notifications, create a custom trigger with an event type of login (requires release 2.5.8.2 or later). Set the threshold to 1 or more to see all logins, or increase it to detect a burst of logins within the interval.
  • Honeypot SMB share: To detect an insider threat looking for open shares, create an SMB share with everyone full control and a name that may attract someone browsing the network, such as finance on /ifs/data/honeypot/finance, and add fake file names that look like sensitive data. Create a custom trigger with the share path as the directory criterion, and save it. Test the trigger by accessing files on the share.

Data Loss Prevention​

Data Loss Prevention (DLP) monitors users who copy files from any secured share or path. It provides real-time monitoring of secured data against bulk copy operations that are unauthorized or that indicate a potential data loss scenario.

The feature monitors the capacity of the file system path using an auto-applied accounting quota. You set the percentage of data any single user can read from the path before the audit trigger fires.

DLP provides the following capabilities:

  • Monitors secure data access by users
  • Alerts administrators of access events with date, time, and IP address
  • Protects against bulk copying of secure data
  • Provides visibility into user data access
  • Secures sensitive data from insider threats
info

The selected path must have a corresponding smart quota created on PowerScale.

To ensure this trigger works correctly, PowerScale must audit close_file_modified and close_file_unmodified events. Run the following command to configure this:

isi audit settings modify --add-audit-success close_file_modified,close_file_unmodified --zone <your-zone>

Configure Data Loss Prevention​

  1. Navigate to Data Security → Threat Detections → Detection Controls → Active Auditor.

  2. Click + Create Trigger, select Data Loss Prevention, and click Next.

  3. Under Basic Configuration, fill in the following fields:

    • Trigger Name — Enter a name for this trigger.

    • Path — Enter the directory path to monitor.

      Best Practice

      Enter a path that matches a share path you are already monitoring.

    • Limit — Use the slider to set the threshold percentage. Pre-filled with a default of 10% — this is a starting value, not just a recommendation.

    • Within — Define the time window during which copying must cross the threshold, pre-filled with a default of 1 minute:

      • Value — Enter a numeric value (for example, 1).
      • Unit — Choose a time unit (for example, Minute(s)).
      Best Practice

      The rate at which copying occurs can affect trigger detection. Set the time period low enough to ensure the threshold is crossed. Adjust the value up or down based on trigger testing results.

  4. Choose one or both of the following response actions:

    • Email Alert — Sends an alert containing the user, path, and policy criteria that were crossed.

    • User Lockout — Denies SMB access to the user on the first share above the monitored path.

      Best Practice

      Enable both Email Alert and User Lockout for DLP events.

  5. Select Save to create the trigger, or Cancel to discard changes. The new trigger appears in the trigger list under Active Auditor — see Editing and managing existing triggers below to edit, delete, or disable it.

Editing and managing existing triggers​

  • Edit: Click the three-dot menu (...) on a trigger row and select Edit.
  • Delete: Click the three-dot menu and select Delete, or select the checkbox and use the trash icon.
  • Enable/disable: Use the status toggle in the Status column to suspend a trigger without deleting it.

Manage Active Auditor Events​

Active Auditor events are managed on the Threat Detections page (Data Security → Threat Detections), alongside Ransomware Defender events, and follow the same event states, detail panel, and Take an Action menu. See Threat Detection — Features for the full reference on event states, the Investigate & Recover page, and the Close Event wizard.

The event detail panel for an Active Auditor event shows the same information as a Ransomware Defender event: affected user, detection timestamp, Signal Strength breakdown by trigger, and the Top Events file operation chart. A sample of files that triggered the detector is available in the panel, with the full list available via CSV export from the Investigate & Recover → Items & Recovery tab.

Use Take an Action to respond to an Active Auditor event, following the same options available per state as Ransomware Defender events (Acknowledge, Lockout Now, Stop Lockout Timer, Restore User Access, Create/Delete Snapshot, Add Comment). Close the event using the Close Event wizard, selecting False Positive (with a learning scope), Close as Threat, or Unexpected but Not a Threat.

Display Historical Active Auditor Events​

Switch to the History tab on the Threat Detections page to see all closed Active Auditor events. You can search and filter using the same criteria as the Active tab, plus filter by closing classification.

See also​