Detection Controls and False Positive Management

Overview

The Detection Controls page is where you configure what the system monitors, how it learns from your environment, and how you manage false positives over time. It combines three distinct concerns into one location:

• Active Auditor — policy-based triggers for specific behaviors (mass deletion, data exfiltration, custom rules) — configuration is covered under Threat Detection and Severity Settings — Active Auditor; this page focuses on the other two concerns below.
• False positive management — tools to suppress known-good activity at varying levels of scope and precision
• Suspicious Extensions — the list of file extensions that feed the extension-based threat detector Navigate to Data Security → Threat Detections → Detection Controls in the left sidebar.

The page has six tabs: Active Auditor, Learned Thresholds, Ignored List, Monitor Only, Suspicious Extensions, and Settings. The Settings tab is covered in Threat Detection and Severity Settings and Snapshot Settings.

Active Auditor trigger types (Mass Delete, Data Loss Prevention, Custom Trigger), how to create and manage triggers, and its Cyber Recovery Manager integration are documented under Threat Detection and Severity Settings — Active Auditor. This page covers false positive management and Suspicious Extensions below.

---

False positive management

The system provides several complementary tools to manage false positives. They differ in scope, precision, and how they interact with the detection pipeline:

Tool	Scope	Detection still runs?	Events raised?	Learning?
Learned Thresholds	Per user, path, or group	Yes	Harder to trigger	Yes — via event closure
Application Fingerprinting	Per behavioral pattern (ML)	Yes	Suppressed if matched	Yes — continuous
Ignored List	Per path / user / IP	No — events dropped before processing	No	No
Monitor Only	Per path / user / IP	Yes	No	No

The recommended order to reach for these tools

Start with Application Fingerprinting (AFP) and Learned Thresholds. These are the primary mechanisms for false positive management and should be your first response in almost every case. They suppress known-safe activity without creating gaps in your detection coverage — the system keeps watching, keeps learning, and keeps building a more accurate picture of your environment over time. Every false positive you classify correctly makes the system smarter.

Use Monitor Only when you need to protect specific entities from lockout — but only while operating in Enforcement or Critical mode. Monitor Only is the right tool when you have a path, user, or IP that you know will trigger detections due to legitimate high-volume activity, and you cannot yet have that entity locked out. Events for Monitor Only entries are still detected, still raised, and still visible on the Threat Detections page as warnings — you retain full visibility.

Use the Ignored List only as a last resort. Adding any path, user, or IP to the Ignored List removes it entirely from the detection pipeline — no events are raised, no activity is logged for detection purposes, no blind spot is visible on the Threat Detections page. The Ignored List is appropriate for paths containing genuinely non-critical data that can be easily recreated (for example, temp directories or scratch paths), or for known automation accounts on fully isolated segments where the operational cost of false positives cannot be managed any other way.

Key principle: Application Fingerprinting and Learned Thresholds suppress known-safe behavior while keeping detection active. Ignored List removes detection entirely. When in doubt, use the learning tools first.

---

Learned Thresholds

The Learned Thresholds tab displays threshold multiplier overrides that adjust detection sensitivity for specific users, paths, or groups. Instead of changing the global Signal Strength thresholds, a multiplier scales the required threshold specifically for that entry — for example, a 2.0x multiplier on a path means twice as many events must occur on that path before a detection fires.

Columns:

Column	Description
Entry	Path, user SID, or group identifier the threshold applies to.
SID	Active Directory SID of the associated user or group, if applicable.
Threat Detector	Which specific detector this threshold modifies (for example: Mass Delete, Suspicious Extension).
Multiplier	How much the standard threshold is scaled (for example: 1.8x means 80% more activity is required to fire).

How entries are created

Learned Thresholds entries are created in two ways:

1. Automatically — when you close an event as False Positive through the Close Event wizard and select a learning scope (this user, this path, this group, or all users). The system creates or updates the relevant entry here.
2. Manually — you can create entries directly in this tab if you know in advance that a specific user or path operates at higher-than-typical volume.

Managing entries

Use Search entries to filter by path or user. Click the trash icon to delete an entry.

Caution: Deleting a learned threshold restores standard detection sensitivity for that entry. If the entry was suppressing a known false positive, similar events will be raised again after deletion.

Applying a learned threshold beyond a single user

By default, flagging an event as a false positive updates the Learned Thresholds entry for the current user only. To apply the new threshold more broadly — to a user group, globally across all users, or to a specific path — the generic threshold feature must first be enabled from the CLI:

igls rsw genericthresholds set --enabled=true

Once enabled, the Take an Action → Archive as False Positive workflow presents four scope options instead of just the current user:

Scope	Effect
Current user	Same as the default behavior — updates the threshold for this user only.
Selected user groups	Applies the new threshold to every user in the selected AD group(s).
All users (global)	Applies the new threshold across the entire environment. A confirmation warning is shown before applying, given the scope of impact.
Selected path	Applies the new threshold to the chosen path regardless of which user triggers future events there.

If the selected path (or user/group) already has an existing multiplier, you are prompted to either use the existing multiplier (archives the event without changing the multiplier) or expand it (increases the multiplier using the same calculation as a normal learning event). If other active events share signals under the same path, they are listed so you can choose whether to archive them at the same time — any not selected remain active and are not factored into the new multiplier.

New or updated entries from any of these scopes appear in the Learned Thresholds tab alongside per-user entries.

---

Application Fingerprinting

Application Fingerprinting is an automated false-positive suppression system that uses machine learning to identify and filter events caused by known, safe application behavior. It runs as a service integrated directly into the Eyeglass appliance — no additional hardware is required.

When Ransomware Defender detects a suspicious event, Application Fingerprinting compares the behavioral characteristics of that event against a database of known application fingerprints. If the event matches a known safe pattern above a confidence threshold, it is suppressed before it reaches the Active Events list.

How it works

The fingerprinting service processes events through a multi-stage pipeline:

1. Event capture — Ransomware Defender identifies suspicious file activity based on configured detection thresholds.
2. Fingerprint comparison — The event's behavioral characteristics (file operation patterns, paths, threat detector set) are compared against the fingerprint database using vector similarity search (FAISS).
3. Confidence scoring — A score from 0 to 1 is calculated based on similarity to known application patterns.
4. Alert decision:
   • If the score exceeds the configured threshold: the event enters Threat Assessment state in Active Events while waiting for the event expiration timer. Once the timer expires, the event is stored in History with the state Known Behavior.
   • If the score falls below the threshold: the event moves from the pending queue to Active Events and the standard lockout and notification workflow applies. The ML model used is paraphrase-multilingual-MiniLM-L12-v2, which supports over 50 languages.

Event states in the new UI

In the new interface, Application Fingerprinting introduces two states visible in the Threat Detections page:

State	Where it appears	What it means
Threat Assessment	Active Events tab, filtered out by default	The event is being evaluated by Application Fingerprinting. The system is waiting for the event timer to expire before making a final determination. No lockout occurs yet.
Known Behavior	History tab	The event was assessed by AFP and matched a known safe application pattern. It was suppressed — no lockout occurred, no alert was sent. The full event detail is preserved for audit purposes.

New GUI only: There is no separate Pending Events tab. Events in Threat Assessment state live on the Active Events tab alongside other active events, but are filtered out of the list by default — enable Show → Events in Assessment to see them. Events raised by Security Guard are filtered out of the Active list the same way, via Show → Security Guard.

Manual actions on Threat Assessment events

While an event is in Threat Assessment state, administrators can still act on it from the Take an Action menu:

Action	Effect
Archive as False Positive	Marks as false positive. Updates the AFP learning database and the Learned Thresholds tab. Event appears in History as False Positive.
Archive as Known Behavior	Marks as safe without AFP learning. Event appears in History as Known Behavior.
Archive as Unresolved	Closes without classification. Event appears in History as Unresolved. Events closed as Unresolved are not learned by the AFP database during normal operation — the one exception is the automatic ingestion performed during the 2.14.1/2.15.0 upgrade itself; see Automatic event ingestion on upgrade to 2.14.1 / 2.15.0 below.
Create Snapshots	Creates snapshots on affected OneFS resources for investigation or recovery.
Mark as Warning or Monitor	Moves the event from Threat Assessment to the Active Events queue, bypassing AFP suppression for this event.
Add Comment	Adds a note to the event while keeping it in Threat Assessment state.

Enabling and disabling

Application Fingerprinting is enabled by default. To disable it, edit the active configuration file on the Eyeglass appliance:

/opt/superna/sca/data/system.xml

Set:

<enableAppFingerprinting>false</enableAppFingerprinting>

Then restart the SCA service. When disabled, all events are processed through the standard Ransomware Defender workflow without fingerprint verification.

Important: Always make configuration changes in /opt/superna/sca/data/ — not in /opt/superna/sca/conf/. The conf/ directory contains default values that are overwritten during upgrades. Changes in data/ are preserved.

Configuration file locations

Application Fingerprinting runs as an integrated service on the Eyeglass appliance — no separate VM or additional hardware is required. Its configuration and data files are split across two directory trees:

Path	Purpose
/opt/superna/sca/conf/system.xml	Default client configuration, refreshed during Eyeglass installation/upgrade.
/opt/superna/sca/data/system.xml	Active client configuration — make all customer changes here.
/opt/superna/sca/conf/appfingerprinting/	Default server configuration, refreshed during Eyeglass installation/upgrade.
/opt/superna/sca/data/appfingerprinting/	Active server configuration and operational data — make all customer changes here.

At startup, Eyeglass merges the conf and data directories. If the same parameter is defined in both, the data value takes precedence. This is what allows customer configuration changes to survive an Eyeglass upgrade even though the conf directory's defaults are replaced each time.

Client configuration parameters

All client parameters are configured in /opt/superna/sca/data/system.xml. Changes require an SCA service restart.

Parameter	Description	Default
enableAppFingerprinting	Enables or disables the feature.	true
appFingerprintingPendingTimerSec	How long the system waits in Threat Assessment state before finalizing the decision.	120
appFingerprintingTailThreshold	Minimum similarity score to classify an event as known behavior.	0.7
appFingerprintingHigherThreshold	Threshold for high-confidence suppression.	0.7
appFingerprintingPathsThreshold	Minimum similarity score for path pattern matching.	0.7
appFingerprintingServerConnectTimeoutSec	Maximum wait time to connect to the fingerprinting service.	5
appFingerprintingServerRequestTimeoutSec	Maximum wait time for a response from the fingerprinting service.	60
appFingerprintingServerPort	TCP port used by the fingerprinting service.	50000
appFingerprintingIgnoreTDs	When true, Threat Detector evaluation is bypassed during fingerprint matching.	false

Port changes: If you change appFingerprintingServerPort, update both data/system.xml (client) and data/appfingerprinting/app_fingerprinting_config.json (server). Changing only one will cause a communication failure.

Server configuration parameters

Server parameters are configured in /opt/superna/sca/data/appfingerprinting/app_fingerprinting_config.json. Changes require sudo systemctl restart app-fingerprinting.

Parameter	Description
blacklisted_threat_detectors	Threat Detectors (by ID) excluded from fingerprint matching. Events matching these TDs always generate alerts regardless of fingerprint results. Defaults: TD6, TD11, TD7.
port	TCP port the fingerprinting service listens on. Must match client configuration.

Example server configuration:

{
  "server": {
    "host": "127.0.0.1",
    "port": 50000,
    "workers": 1,
    "log_level": "INFO"
  },
  "model": {
    "name": "//opt//models//paraphrase-multilingual-MiniLM-L12-v2",
    "dimensions": 384,
    "batch_size": 128
  },
  "database": {
    "path": "./faiss_db",
    "tail_k": 4,
    "higher_k": 4,
    "drop_filename": true
  },
  "search": {
    "tail_similarity_threshold": 0.7,
    "higher_similarity_threshold": 0.7,
    "min_similar_paths": 0.7,
    "max_workers": 8,
    "max_partitions_in_memory": 50,
    "embedding_cache_size": 10000,
    "blacklisted_threat_detectors": [
      "THREAT_DETECTOR_06",
      "THREAT_DETECTOR_11",
      "THREAT_DETECTOR_07"
    ]
  }
}

Tuning confidence thresholds

The appFingerprintingTailThreshold and appFingerprintingHigherThreshold parameters (both default 0.7) control how strictly the system requires a match before suppressing an event.

Threshold range	Effect	Recommended for
0.85–0.95 (higher, stricter)	Fewer events suppressed. More alerts sent to security team. Lower risk of missing threats.	High-security environments, early deployment phases.
0.60–0.75 (lower, more aggressive)	More events suppressed. Fewer alerts. Higher risk of missing subtle threats.	Mature deployments, high false-positive environments, well-understood application behavior.

Recommended tuning process:

1. Start with the default threshold of 0.7.
2. Monitor alert volume and the History tab for two to four weeks.
3. Review Known Behavior events to confirm they are genuinely safe.
4. If false negatives appear (real threats being suppressed), increase thresholds by 0.05–0.10.
5. If false positive rate remains high, decrease thresholds by 0.05–0.10.
6. Repeat.

Automatic event ingestion on upgrade to 2.14.1 / 2.15.0

When upgrading to 2.14.1 or 2.15.0, the system automatically ingests historical events from the database into the AFP learning database as part of the upgrade itself — including events in both the False Positive and Unresolved states. This gives AFP an initial baseline of known-safe behavior drawn from your existing event history, with no manual action required.

After this one-time upgrade ingestion, ongoing AFP learning reverts to the behavior described above: only events subsequently closed as False Positive feed the AFP database. Events archived as Unresolved after the upgrade are not learned from — the inclusion of Unresolved events is specific to the automatic ingestion that runs during the 2.14.1/2.15.0 upgrade, not to day-to-day learning.

Learning management — uploading historical events

Manually uploading historical events into the AFP database is being replaced by the automatic upgrade ingestion described above — see Automatic event ingestion on upgrade to 2.14.1 / 2.15.0. The full manual upload procedure (Threat Analyzer file generation, the /addFromCsv upload, and validation steps) is documented in the 2.14.0 release of this page, kept there in case it's still needed for an environment not covered by the automated ingestion.

AFP API reference

All endpoints require a valid Bearer token in the Authorization header. The service runs on localhost port 50000 by default.

Endpoint	Method	Description
/	GET	Returns server info and available endpoints.
/health	GET	Health check — returns uptime, status, and start timestamp.
/faissDbStatus	GET	Returns database status: partition stats, memory usage, and configuration.
/addFromCsv	POST	Loads events from a CSV into the AFP database. Duplicate entries are filtered automatically.
/cleanFaissDb	POST	Permanently deletes all AFP database content. This action cannot be undone.
/setAuthToken	POST	Sets a new Bearer token. Requires the current valid token. Takes effect immediately.
/resetAuthToken	POST	Resets to the default token. Requires the current valid token.

Health check example:

curl -X GET http://127.0.0.1:50000/health -H "Authorization: Bearer <token>"

Expected response:

{
  "status": "healthy",
  "service": "partitionedVectorDbServer",
  "uptime": "02:15:30",
  "uptime_seconds": 8130,
  "start_timestamp": "2026-01-13T10:30:00.000000"
}

Warning: POST /cleanFaissDb permanently deletes all AFP database content. Do not call this endpoint unless you intend to fully reset the AFP learning database.

---

Ignored List

The Ignored List configures paths, users, and source IPs that are completely excluded from ransomware detection. Audit events matching any entry are dropped before processing — no Signal Strength accumulates, no event is raised, no alert is sent.

Navigate to Detection Controls → Ignored List.

Use for: Paths containing genuinely non-critical data that can be easily recreated (for example, temp directories or scratch paths), or known automation accounts on fully isolated segments where the operational cost of false positives cannot be managed any other way. Use only as a last resort.

Do not use for: Paths containing sensitive data where you still need visibility. Use Monitor Only instead.

Adding an entry

1. Click Add + in the top-right corner.
2. Select the type: Path, User, or Source/Client IP.
3. Enter the value:
   • Path (PowerScale): Full path required, for example /ifs/data/backup/. Wildcard patterns supported (see below).
   • User (AD): domain\userid or user@domainname. Domain must be uppercase.
   • User (ECS): Object user name (for example: object_user) or URN format (for example: urn:ecs:iam::ns1:user/test).
   • Source/Client IP: IP address of a client machine or server.
4. Select the Managed Device this rule applies to.
5. Save.

Pattern matching

PowerScale

Pattern	Matches
/ifs/data/home/*/	Any single directory under /ifs/data/home/
/ifs/data/home/userx/*	Any file directly inside the userx folder
/ifs/path/*.java	Any .java file in that specific path
/ifs/**.java	Any .java file on any path under /ifs/
/ifs/path/*.*	Any file with any extension in that path
/ifs/path/*.{java,class}	Any file ending in .java or .class
/ifs/path/foo.?	Files named foo. with a single-character extension

ECS

Pattern	Matches
**	All objects across the entire ECS cluster
*/path/to/object	A specific path in any bucket
<bucket>/path/*	All direct children of a path
<bucket>/path/**	All descendants of a path
<bucket>/path/to/object	An exact object

Matching logic: Each column (path, user, source IP) is evaluated with OR logic. If any ignore value matches an audit event, the event is dropped at the first match found.

Converting to Monitor Only

If you want to change Ignored List entries so they raise Monitor-mode events instead of being dropped outright, click Convert Entries to Monitor Mode. All current Ignored List entries are moved to the Monitor Only list. A confirmation dialog appears before the conversion is applied.

---

Monitor Only list

The Monitor Only list configures paths, users, and sources where activity is processed and detection runs normally, but any resulting event is raised in Monitor mode: it appears on the Threat Detections page like any other event, snapshots are still taken, and no automatic lockout occurs — an administrator can still apply a manual lockout if needed. Unlike the Ignored List, which drops matching audit events before they're processed at all, Monitor Only entries still flow through the full detection pipeline; visibility without automatic enforcement is the point.

Navigate to Detection Controls → Monitor Only.

Use for: Paths or users where you want full audit visibility but are not yet ready for automated enforcement. Useful during initial deployment, for trusted service accounts, or for activity you want to observe before deciding whether to fully ignore or fully enforce.

Adding an entry

The process is identical to the Ignored List. Click Add +, select Path or User, enter the value, select the managed device, and save.

To enable Monitor Only for an entire ECS cluster, set the path to ** (double asterisk) and select the ECS device.

---

Whitelist Assessment Tool

Old GUI only

Available in the old GUI only for now.

The Whitelist Assessment Tool is a utility that helps you evaluate which paths and users in your environment should be candidates for the Ignored List or Monitor Only list, based on historical audit activity patterns.

It was replaced by Application Fingerprinting — an advanced set of models that detects similar behavior. We recommend relying on Application Fingerprinting first; see Application Fingerprinting above.

In the old GUI, it is accessible on the Active Events page. This tool doesn't have a dedicated page in the current documentation set — Application Fingerprinting above is the current recommended replacement and receives ongoing documentation updates.

---

Suspicious Extensions

The Suspicious Extensions tab manages the list of file extensions that feed the Suspicious Extension threat detector. When a user performs file operations involving any enabled extension, it contributes to that user's Signal Strength.

Navigate to Detection Controls → Suspicious Extensions.

The list is maintained by Superna and updated automatically. The Last Updated timestamp shows when the list was last refreshed from the Superna threat intelligence feed. See File Extension Whitelist for how the master list is maintained and the CLI commands to control update mode.

Managing extensions

Action	How
Disable an extension	Click the State dropdown for that extension and select Disabled. The extension remains in the list but is not evaluated.
Enable a disabled extension	Click the State dropdown and select Enabled.
Add a custom extension	Click Add + and enter the extension including the leading period (for example: .customext).
Delete an extension	Select the checkbox and click the trash icon. Only available for extensions you added yourself — the Superna-maintained list cannot be deleted; disable a built-in extension instead (see above).

When to disable: Only disable an extension if it generates sustained false positives in your environment (for example, a legitimate application creates files with that extension) and you cannot address the issue through Learned Thresholds or Application Fingerprinting. Each disabled extension is a gap in your ransomware coverage.

When adding for testing: Use a unique extension not present anywhere in your production environment. See Health Check — Testing with a Custom File Extension for the recommended test procedure.

Multi-word custom extensions: A known issue can prevent a custom extension made up of two words from being removed in the New GUI — see Release Notes — Known Issues.

Closing an event as False Positive disables the extension environment-wide. If an event involving a suspicious extension is closed as False Positive, that extension is disabled across the entire environment — not just for the user or path involved. To reverse this, an administrator must first delete the corresponding Learned Threshold entry before the extension can be re-enabled.

---

See also

• File Extension Whitelist — How the Suspicious Extensions master list is maintained and updated.
• Threat Detection and Severity Settings — How detectors feed into Signal Strength and severity levels, and Active Auditor trigger configuration.
• Threat Detection — Features — Event lifecycle including the AFP Threat Assessment and Known Behavior states.
• Health Check — Security Guard — Validate your detection configuration with automated simulated attacks.