Threat Detections

Overview

This section covers the operational use of the Threat Detections page — how to interpret events, how to work through the triage workflow for each severity level, how to recover data when a real attack is confirmed, and how the system learns from your feedback to improve over time.

For configuration of detection thresholds, enforcement modes, and detector settings, see Threat Detection and Severity Settings.

Navigate to Data Security → Threat Detections in the left sidebar.

The page has two tabs, Active and History. Each lists events with the following columns: Severity, State, User/Client IPs, Device, Threat Category, Similarity Score, Event ID, and Time Detected. Severity, State, Device, Threat Category, Time, and Show filters narrow the list.

By default, the Show filter excludes two categories of event from the Active list: events in Threat Assessment state (see Event states in the new UI), and events raised by Security Guard. Enable Show → Events in Assessment or Show → Security Guard to include them.

---

Security event terminology

Understanding the language used throughout the interface is essential for effective triage.

Term	Definition
File Event	A discrete event published by PowerScale's audit stream based on a user action — for example: open file, close file, write, rename. Each file event is a single data point.
Signal	A group of file events that has been flagged by one or more threat detectors as a potential ransomware-related pattern. A Signal is the unit of detection.
Signal Strength	For a given event, the combined score of all Signals raised during its lifetime. A higher Signal Strength means more detectors fired more frequently. Displayed as a number and a bar in the event list and detail panel.
Threat Detection (also Security Event, informally; formerly Ransomware Event)	A collection of Signals whose combined Signal Strength has crossed the configured Warning threshold for a given user. Once an event exists, it accumulates Signals and escalates severity as Signal Strength grows.
Threat Category	The specific detector(s) that fired — for example: Data Encryption, Suspicious Extension, Honeypot Activity. Multiple categories can appear on a single event.
Similarity Score	The Application Fingerprinting (AFP) score for the event — how closely its behavior resembles a known-safe application pattern AFP has already learned, compared against the configured appFingerprintingTailThreshold (default 0.7). See Application Fingerprinting. Reads N/A for events raised before the 2.14 release, when fingerprinting was introduced.
Impacted Items	The number of files associated with the event detection across all signals.
Client IP	The IP address of the user's machine at the time of the suspicious activity.

---

What's on this page

This section is split across the following subpages:

Event Processing and Actions Available

How an event moves from detection through to closure, the Actions menu, Retain Snapshots, and the Investigate & Recover tabs.

See more

Recovery

Using Recovery Manager to restore data affected by a confirmed ransomware event.

See more

Closing Event

The five closing states an event can reach, and the Close Event wizard used to classify and close one manually.

See more

Security Event States

Every state a security event can be in, when it occurs, and the actions available at each one.

See more

Detection Types

Reference table of every threat detection type (TD1–TD18) and its category.

See more

---

Triage workflow by severity

Warning events

State: Monitor
Automated response: None. A countdown timer begins. The event auto-closes if no further suspicious activity occurs.

How to respond:

1. Open the event. Review the threat categories, Signal Strength breakdown, and top file operations in the slide-out panel.
2. Click Investigate & Recover and review the Items & Recovery and Activity Log tabs.
3. Decide:
   • Legitimate activity: Let the event auto-close, or close it immediately as False Positive with the appropriate learning scope.
   • Suspicious: Use Take an Action → Lockout Now to immediately revoke access — you do not have to wait for the event to escalate to Major.
   • Uncertain: Use Take an Action → Acknowledge to prevent auto-close and signal to teammates that the event is under review.

The file list in the detail panel is a sample. For a comprehensive file list, use the CSV download in Items & Recovery, or run a user activity query in Data Auditing → Queries & Reports. The downloaded file is named recovery-items-<timestamp>.csv (for example, recovery-items-1783716244867.csv).

Each row in the CSV lists a signal, not a file. The files cell for each row lists all files related to that signal; in Excel, double-click the cell to see the list. A signal is a pattern of user behavior that affects multiple files. The CSV stores only the first 1,000 files associated with a detection, because storing every file could make it very large. In most cases this covers all affected files, but to get a complete list of files touched by a user, run a user report in Data Auditing. The CSV provides a history of all files that triggered events for a user who has had multiple detections; the current file rolls over and historical files are listed with a date and time stamp. A CSV file can only be downloaded within 28 days (4 weeks) of its creation.

Major events

State: Delayed Lockout
Automated response: Lockout countdown timer begins.

How to respond:

1. Open the event immediately. Note the remaining time on the countdown timer.
2. Review Items & Recovery and Assets tabs on the Investigate & Recover page.
3. Contact the user or their manager to check whether the activity has a legitimate explanation.
4. Before the timer expires:
   • Benign: Stop Lockout Timer → investigate further → close as False Positive or Unexpected but Not a Threat.
   • Malicious or unclear: Lockout Now to apply the lockout immediately.
5. If the timer expires before you act, the lockout applies automatically. Continue from there as a Critical event.

Critical events

State: Lockout
Automated response: Immediate access revocation. Snapshots taken.

How to respond:

1. The user is already locked out. Do not restore access until investigation is complete.
2. Work through all four tabs on the Investigate & Recover page:
   • Items & Recovery: Identify affected files, assess recoverability, and initiate recovery if needed.
   • Snapshots: Verify snapshot creation and identify any gaps.
   • Assets: Confirm the DENY permission is applied to all expected shares.
   • Activity Log: Review the full event timeline.
3. If you confirm this is a real attack, use Recovery to restore affected data before returning user access.
4. Complete your incident response process — scan the user's machine, collect evidence, escalate as required.
5. When ready to restore access: Take an Action → Restore User Access. Monitor the job in the Jobs sidebar section. Verify in Assets tab that DENY entries have been removed.
6. Close the event as Close as Threat using the Close Event wizard.

---

Learning mode explained

"Learning mode" is not a single toggle — it is the combination of several mechanisms that work together to reduce false positives over time as the system accumulates feedback from your classifications.

Event-driven learning (Learned Thresholds): Closing an event as False Positive with a learning scope creates or updates a threshold multiplier in the Learned Thresholds tab. The specific detector is harder to trigger for that user, path, or group going forward.

Application Fingerprinting (automated learning): AFP continuously builds a database of known safe behavioral patterns from events you classify as False Positive. When a new event matches a known pattern above the confidence threshold, AFP suppresses it automatically before it reaches the Active Events list.

Auto-Learn From Events toggle: The Auto-Learn From Events toggle in Detection Controls → Settings → Response Settings controls whether event closures automatically update Learned Thresholds. Enabled by default.

Learning approaches:

• Full learning — Applies to all detected events. No lockouts occur, and all events are used for learning.
• Monitor-list learning — Allows both enforcement and learning of Monitor Only list entries. Events that do not match a Monitor Only list entry are enforced, and lockouts can occur based on thresholds. Learning is applied to events that match an entry. A typical use case is adding service accounts or new application workloads to the Monitor Only list by path, user, or server IP address, so learning configures settings for that workload automatically.

note

While learning is active, many snapshots can be created. Monitor snapshot usage on your cluster. Snapshots are created with a 48-hour expiry by default and are cleaned up within 2 days.

Recommended procedure for a new deployment:

1. Deploy in Monitor mode so that user behaviors are detected without any lockout, and keep learning enabled.
2. Leave learning enabled for 2-3 business days, long enough for the system to see all the workflows in your environment, and monitor the customized settings placed on the Learned Thresholds tab. Learning also places file extension detections it encounters in a disabled state on the Suspicious Extensions list, so that those extensions are not detected as ransomware.
3. Review the entries on the Learned Thresholds tab. Approve the list of users or NFS hosts, or delete entries as needed. Consult Superna Support if you are unsure, or accept the learned behaviors. If a listed user is an application server service account, add it to the Monitor Only list to disable lockouts while still alerting and snapshotting.
4. Review the extensions that learning set to a disabled state. Disabled extensions are on the allowed list and do not trigger a detection. If they are legitimate in your environment, no action is needed. Each extension can be set to one of three states: enabled (full enforcement), disabled (ignored), or monitor (detect, alert, and snapshot, with no lockout). Investigate any extension that does not look legitimate in your environment to verify it is not a ransomware detection.
5. Disable learning once the settings are confirmed. This leaves the system in Monitor mode.
6. To enter enforcement, switch out of Monitor mode.

For new deployments: Expect a higher false positive rate in the first few weeks while AFP builds its baseline. Accurately classifying events as False Positive as early as possible — particularly uploading historical events to the AFP database — significantly accelerates this process. See Application Fingerprinting — Learning Management.

---

See also

• Event Processing and Actions Available — Full event lifecycle, the Actions menu, and Retain Snapshots.
• Recovery — Using Recovery Manager to restore affected data.
• Closing Event — The five closing states and the Close Event wizard.
• Security Event States — Full state and available-actions reference.
• Detection Types — Threat detector categories (TD1–TD18).
• Threat Detection and Severity Settings — Detector types, Signal Strength, severity levels, and enforcement modes.
• Threat Response, Lockout and Snapshots — How lockout works, SMB vs NFS, and restore procedures.
• Snapshot Settings — Snapshot budget logic and critical-path configuration.
• Detection Controls and False Positive Management — Active Auditor, AFP, Ignored List, Monitor Only, and Learned Thresholds.
• Data Auditing — Query file system activity for forensic investigation. Use WireTap for live monitoring during an active event.
• Integrations — Configure SIEM/SOAR webhook integration to involve your SecOps team in event analysis.