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.

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.
  • 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.

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.

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.

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​