Version: 2.14.1

Application Fingerprinting

Overview

Application Fingerprinting is a feature that reduces false positive alerts in Ransomware Defender by identifying and suppressing alerts triggered by known, normal application behavior patterns. The system uses pattern matching to compare new ransomware events against a database of known application fingerprints.

Purpose

Application Fingerprinting improves ransomware detection accuracy by:

Reducing alert fatigue: Automatically suppresses alerts from known safe applications
Improving detection accuracy: Focuses security teams on genuine threats rather than false positives
Maintaining security posture: Continues to monitor and log all activity while filtering noise
Streamlining operations: Reduces manual triage and investigation time

The Application Fingerprinting system continuously learns from validated safe application behavior. When Ransomware Defender detects a suspicious event, the system:

Extracts behavioral characteristics from the event
Compares these characteristics against known application fingerprints
Calculates a confidence score indicating the likelihood that the event represents normal application behavior
Automatically suppresses the alert if the confidence score exceeds the configured threshold

This process ensures that legitimate application activity does not trigger unnecessary security alerts while maintaining vigilance against actual threats.

How Application Fingerprinting Works

Application Fingerprinting uses a multi-stage verification process to distinguish between normal application behavior and potentially malicious activity.

Event Detection and Verification Workflow

When Ransomware Defender detects a suspicious event, the following workflow executes:

Event Capture: Ransomware Defender identifies suspicious file activity based on configured detection thresholds
Fingerprint Comparison: The system analyzes the event and compares it against the application fingerprint database using:
- Behavioral pattern matching
- Threat Detector (TD) set validation
- Path and file operation analysis
Confidence Scoring: A confidence score is calculated based on:
- Similarity to known application patterns
- Exact match of Threat Detector characteristics
- Historical behavior consistency
Alert Decision: Based on the confidence score:
- Score Above Threshold: Event enters the THREAT_ASSESSMENT state while waiting for the event expiration timer (the same timer used in monitor mode).
- Score Below Threshold: Event is moved from Pending Events to Active Events

Event Outcomes

Application Fingerprinting classifies events into different categories based on their similarity to known application patterns:

High Confidence Events (Known Application Behavior)

When the confidence score exceeds the configured threshold:

Event enters the THREAT_ASSESSMENT state while waiting for the event expiration timer (the same timer used for events in monitor mode)
After the timer expires, the event is stored in Historical Alerts with the state KNOWN_BEHAVIOR-Historical
No snapshot is created
No user lockout occurs
Event remains logged for audit and analysis purposes
No alert is sent to the security team

Active Events (Partial or No Match)

When the confidence score falls below the threshold:

Event is moved from Pending Events to Active Events
Standard snapshot and lockout policies apply
Alert is sent to security team for investigation
Full incident response workflow is triggered

Manual Actions for Pending Events

When an event remains in the Pending Events tab after the server verification check, administrators can still perform several manual actions using the Actions menu.

These actions allow security teams to classify or respond to the event while the automatic verification process is still in progress.

The following options are available:

Archive as False Positive: Marks the event as a false positive. The Learned Thresholds tab is updated and the fingerprint database is updated with this behavior. The event appears in Events History with the state False Positive.
Archive as Known Behavior: Marks the event as a known safe behavior. The event appears in Events History with the state Known Behavior.
Archive as Unsolved: Marks the event as unresolved. The event appears in Events History with the state Unsolved.
Create Snapshots: Creates snapshots on the affected OneFS resources for further investigation or recovery.
Mark as Warning or Monitor: Moves the event from Pending Events to the Active Events tab. The state depends on whether monitor mode is enabled in the configured thresholds.
Add Comment: Adds a comment to the event while keeping it in the Pending Events tab. The comment will be visible when the Actions menu is opened again.

Pattern Learning

Application Fingerprinting continuously builds its knowledge base of normal application behavior through:

Analysis of validated safe events
Correlation of file operation patterns
User and application behavioral profiling
Ongoing refinement of fingerprint accuracy

info

The system uses the paraphrase-multilingual-MiniLM-L12-v2 model from sentence-transformers, which supports multiple languages including: ar, bg, ca, cs, da, de, el, en, es, et, fa, fi, fr, fr-ca, gl, gu, he, hi, hr, hu, hy, id, it, ja, ka, ko, ku, lt, lv, mk, mn, mr, ms, my, nb, nl, pl, pt, pt-br, ro, ru, sk, sl, sq, sr, sv, th, tr, uk, ur, vi, zh-cn, zh-tw.

Installation and Deployment

Application Fingerprinting is integrated directly into the Superna Eyeglass appliance. No separate virtual machine or additional hardware is required.

Deployment Architecture

Integrated Service: Application Fingerprinting runs as part of the Eyeglass system
No Additional VM: The feature is deployed within the existing Eyeglass infrastructure
Default Configuration: Pre-configured with recommended settings for immediate use
Network Service: Operates on port 50000 (configurable)

System Files and Directories

Application Fingerprinting configuration and data files are located in the following directories:

Path	Purpose
`/opt/superna/sca/conf/system.xml`	Default configuration file containing Application Fingerprinting client parameters (updated during Eyeglass installation)
`/opt/superna/sca/data/system.xml`	Active configuration file for client parameters - all customer changes must be made here
`/opt/superna/sca/conf/appfingerprinting/`	Default server configuration files (updated during Eyeglass installation)
`/opt/superna/sca/data/appfingerprinting/`	Active server configuration files and operational data - all customer changes must be made here

Configuration File Management

Application Fingerprinting uses two types of configuration files:

Client Configuration (system.xml): Controls how the Ransomware Defender client sends events to the fingerprinting service
Server Configuration (app_fingerprinting_config.json in appfingerprinting/ directory): Controls how the fingerprinting service processes events

Important Configuration Locations

All configuration changes MUST be made in the /opt/superna/sca/data/ directory, not in /opt/superna/sca/conf/. The conf/ directory contains default configurations that are overwritten during Eyeglass upgrades. Any changes made to files in conf/ will be lost during the next installation.

Configuration Merge Behavior

Eyeglass loads configuration files from both the conf and data directories.

During startup, the system merges both configurations. If the same parameter exists in both files, the value from the data directory takes precedence.

This mechanism ensures that customer configuration changes are preserved during upgrades, even when the default configuration in the conf directory is replaced.

Client changes: Edit /opt/superna/sca/data/system.xml
Server changes: Edit /opt/superna/sca/data/appfingerprinting/app_fingerprinting_config.json

Restart Requirements

Client configuration changes (system.xml): Require an SCA restart
Server configuration changes (app_fingerprinting_config.json): Require a service restart using sudo systemctl restart app-fingerprinting

Enabling and Disabling Application Fingerprinting

Application Fingerprinting is controlled through the enableAppFingerprinting parameter in the system.xml configuration file.

Default State

Application Fingerprinting is enabled by default in the /opt/superna/sca/conf/system.xml file. It remains active unless explicitly disabled in /opt/superna/sca/data/system.xml.

Enable Application Fingerprinting

To enable the feature (if previously disabled):

Open the active configuration file:
```
/opt/superna/sca/data/system.xml
```

Locate or add the enableAppFingerprinting parameter:

<enableAppFingerprinting>true</enableAppFingerprinting>

Save the file
Restart the SCA service

Disable Application Fingerprinting

To disable the feature:

Open the active configuration file:
```
/opt/superna/sca/data/system.xml
```

Set the enableAppFingerprinting parameter to false:

<enableAppFingerprinting>false</enableAppFingerprinting>

Save the file
Restart the SCA service

note

When Application Fingerprinting is disabled, all events are processed through the standard Ransomware Defender workflow without fingerprint verification.

Configuration Options

Application Fingerprinting provides multiple configuration parameters to fine-tune detection behavior and system performance.

Client Configuration Parameters

All client parameters are configured in /opt/superna/sca/data/system.xml.

Parameter	Description	Default Value	Restart Required
`enableAppFingerprinting`	Enables or disables the Application Fingerprinting feature	`true`	Yes (SCA)
`appFingerprintingPendingTimerSec`	Time in seconds to wait for fingerprint verification before continuing normal processing	`120`	Yes (SCA)
`appFingerprintingTailThreshold`	Similarity threshold for the tail index, which matches the deepest components of a path (the final subdirectories and, unless dropped, the file name)	`0.7`	Yes (SCA)
`appFingerprintingHigherThreshold`	Similarity threshold for the higher index, which matches the path components directly above the tail	`0.7`	Yes (SCA)
`appFingerprintingPathsThreshold`	Minimum similarity score required for path pattern matching	`0.7`	Yes (SCA)
`appFingerprintingServerConnectTimeoutSec`	Maximum time in seconds to wait for connection to the fingerprinting service	`5`	Yes (SCA)
`appFingerprintingServerRequestTimeoutSec`	Maximum time to wait for a response from the fingerprinting service	`60`	Yes (SCA)
`appFingerprintingServerPort`	TCP port used by the fingerprinting service	`50000`	Yes (SCA)
`appFingerprintingIgnoreTDs`	When set to `true`, Application Fingerprinting bypasses Threat Detector evaluation. TD signals are ignored during fingerprint matching	`false`	Yes (SCA)

Port Configuration

If you change the appFingerprintingServerPort parameter, you must update both the client configuration (data/system.xml) and the server configuration (data/appfingerprinting/app_fingerprinting_config.json) to ensure the client sends data on the new port and the server listens on the new port. Changing only one file will result in communication failure.

Server Configuration Parameters

Server parameters are configured in /opt/superna/sca/data/appfingerprinting/app_fingerprinting_config.json.

Parameter	Description	Restart Required
`blacklisted_threat_detectors`	Comma-separated list of Threat Detector (TD) identifiers to exclude from fingerprint matching. Events matching these TDs will bypass fingerprint verification and always generate alerts	Yes (service)
`port`	TCP port on which the fingerprinting service listens (must match client configuration)	Yes (service)

Server Configuration Example

app_fingerprinting_config.json

{
  "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"
    ]
  }
}

Parameter Precedence

When the same parameter exists in both client and server configuration files, the client parameter takes precedence for client-side behavior (such as thresholds and timeouts), while the server parameter controls server-side behavior (such as port listening and TD exclusions).

Parameter Impact and Tuning

Confidence Thresholds

The confidence threshold parameters control how aggressively Application Fingerprinting suppresses alerts.

Application Fingerprinting does not compare a path as a single string. Each path is split into two groups of components, and each group is matched against its own index with its own threshold:

appFingerprintingTailThreshold applies to the tail index — the deepest components of the path, that is, the final subdirectories and, unless dropped, the file name.
appFingerprintingHigherThreshold applies to the higher index — the components directly above the tail.

The two are evaluated independently, which is why both use the same default of 0.7; the shared default does not mean they are interchangeable. Lowering the tail threshold makes matching more tolerant of variation in the final subdirectory and file name. Lowering the higher threshold makes it more tolerant of variation in the directory tree above. Environments with a stable upper tree and heavy churn below tune the first; environments with the opposite pattern tune the second.

Higher Threshold Values (e.g., 0.85-0.95):

More strict detection
Fewer events suppressed
More alerts raised to security team
Recommended for high-security environments

Lower Threshold Values (e.g., 0.60-0.75):

More aggressive suppression
More events filtered as normal behavior
Fewer alerts raised to security team
Recommended when false positive rate is high

Tuning Recommendation

Start with the default thresholds and adjust based on your environment's alert volume and false positive rate. Monitor Historical Alerts to ensure legitimate threats are not being suppressed.

Timeout Configuration

The timeout parameters (appFingerprintingPendingTimerSec, appFingerprintingServerConnectTimeoutSec, appFingerprintingServerRequestTimeoutSec) control how long the system waits for fingerprint verification:

Shorter Timeouts: Faster event processing, but may skip verification if the service is busy
Longer Timeouts: More reliable verification, but slower event processing

Fallback Behavior

If the Application Fingerprinting service does not respond within the configured timeout, the event is processed through the standard Ransomware Defender workflow without suppression.

Threat Detector Exclusions

The blacklisted_threat_detectors parameter in the server configuration allows specific Threat Detectors to bypass fingerprint verification:

{
  "blacklisted_threat_detectors": ["TD001", "TD005", "TD012"]
}

Use this parameter to ensure critical threat patterns always generate alerts regardless of fingerprint matches.

Configuration Location

The blacklisted_threat_detectors parameter is configured in the server configuration file (data/appfingerprinting/app_fingerprinting_config.json), not in system.xml. Changes require a service restart using sudo systemctl restart app-fingerprinting.

Operational Behavior and Impact

Application Fingerprinting integrates seamlessly with Ransomware Defender and modifies event processing behavior based on fingerprint verification results.

Impact on Alert Processing

When Application Fingerprinting is enabled:

Alert Volume

Reduced Alert Count: Events matching known application fingerprints are automatically suppressed
Improved Signal-to-Noise Ratio: Security teams receive fewer false positives
Maintained Visibility: All events, including suppressed ones, are logged in Historical Alerts

Snapshot Creation

Suppressed Events: No snapshots are created for events classified as known application behavior
Active Events: Snapshots are created normally for events that do not match fingerprints
Storage Savings: Reduced snapshot volume lowers storage consumption

User Lockout Behavior

Suppressed Events: No user lockout occurs for events classified as known application behavior
Active Events: Standard lockout policies apply for events that do not match fingerprints
Operational Continuity: Legitimate users experience fewer disruptions

Historical Alert Storage

All events processed by Application Fingerprinting are stored in the Historical Alerts database, regardless of whether they were suppressed or raised as active alerts.

Suppressed events include:

Full event details
Confidence score
Event state (KNOWN_BEHAVIOR-Historical)
Timestamp and user information
File paths and operation types

This ensures complete audit trails and enables retroactive analysis if threat patterns change.

Application Fingerprinting Learning Management

After upgrading, complete this step to improve Application Fingerprinting (AFP) performance.

To ensure AFP can learn from your environment, manually upload your historical events to the AFP database. Before uploading, you can filter out any events you do not want included.

This step is especially important because:

It accelerates the AFP learning process by incorporating past events.
In monitor mode (with learning disabled), events are automatically closed as unresolved.
Unresolved events are not learned by the AFP database.
Environments that do not mark events as false positives will not benefit from automatic learning without this upload.

By uploading historical events, AFP builds a more complete baseline and delivers more accurate results sooner.

Step 1: Confirm a Threat Analyzer File Is Available

A Threat Analyzer (TA) file is the source data for populating the AFP database. Before running the upload, verify that a recent TA file exists on your Eyeglass appliance.

Check for Existing Files
Log in to your Eyeglass appliance and navigate to the TA output directory:
```
/opt/superna/logParser/threatAnalyzer/files/
```
Review the files present. Superna recommends using a TA file created within the last 3 months. If the files are older than 3 months, or if no files exist, proceed to step 2 to generate a fresh file.
Generate a New Threat Analyzer File (If Needed)

SSH as Root Required
You must connect as root to run the Threat Analyzer. Admin-level SSH access is insufficient for this step.

Connect to Eyeglass via SSH as root, then run the following commands.

Navigate to the Threat Analyzer directory:
```
cd /opt/superna/logParser/threatAnalyzer
```
Run the Threat Analyzer:
```
java -jar "Eyeglass Threat Analyzer.jar" -d eyeglass-uba -c test_customer -ip localhost -v
```
Once the process completes, the output file will be written to:
```
/opt/superna/logParser/threatAnalyzer/files/
```

Step 2: Upload Events to the AFP Database

With a valid Threat Analyzer file confirmed, run the following curl command to push the events into the AFP database.

Authentication
The API requires a Bearer token. Contact support at support@superna.net to receive the token.

Token configuration files (override takes precedence):
- /opt/superna/sca/conf/appfingerprinting/app_fingerprinting_config.json — base config
- /opt/superna/sca/data/appfingerprinting/app_fingerprinting_config.json — override (takes precedence)

Run the Upload Command
Replace the csv_path value with the full path to your TA file:

curl -X POST "http://127.0.0.1:50000/addFromCsv" \
  -H 'Authorization: Bearer <token>' \
  -H "Content-Type: application/json" \
  -d '{"csv_path": "/opt/superna/logParser/threatAnalyzer/files/<your_file.csv>"}'

Example with a real filename:

curl -X POST "http://127.0.0.1:50000/addFromCsv" \
  -H 'Authorization: Bearer <token>' \
  -H "Content-Type: application/json" \
  -d '{"csv_path": "/opt/superna/logParser/threatAnalyzer/files/logparser_threat_analyzer_2026_03_02_13_44_09.csv"}'

Do Not Interrupt the Process

Even the largest files take approximately 6 minutes to process. Do not press Ctrl+C to interrupt the process. If the command appears to be running longer than expected, let it continue.

note

Rows in the CSV that contain TD6, TD11, or TD7 threat detector entries are blacklisted and excluded from the AFP database automatically.

Step 3: Monitor Progress via Log Tailing

There is no built-in progress bar for the upload command. Open a new terminal window and tail the AFP log file to monitor processing status in real time:

tail -f /opt/superna/sca/logs/app-fingerprinting.log-20260317

Update the Log Date

The log filename includes a date suffix. Replace 20260317 with the current date in YYYYMMDD format to tail the correct file.

Step 4: Validate the Vector DB Was Created Successfully

After the curl command completes, verify that the AFP vector database was built correctly. Run both commands below and review the output.

List Vector DB Files
This confirms the database partitions and index files were written to disk:
```
ls -l /opt/.pyenv/versions/3.12.2/envs/pygls/lib/python3.12/site-packages/pygls/app_fingerprinting_server/faiss_db/
```
A successfully populated database shows one or more partition subdirectories along with index and metadata files. If the directory is empty or missing, the upload did not complete successfully — re-run Step 2.
Check Vector DB Disk Usage
This confirms the database has a non-trivial size, indicating data was written:
```
du -h /opt/.pyenv/versions/3.12.2/envs/pygls/lib/python3.12/site-packages/pygls/app_fingerprinting_server/faiss_db/
```
The reported size will vary depending on the number of events ingested. A result of 0 bytes or a missing path indicates the upload failed. Check the log file (Step 3) for errors and retry the curl command.

Healthy Result

You should see multiple files listed under the faiss_db/ directory (ls -l), and the du -h output should show a non-zero total size. Both checks together confirm the vector database was created and populated correctly.

API Reference

The AFP server exposes the following endpoints on localhost port 50000. All requests require a valid Bearer token in the Authorization header.

Authentication header format:

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

Managing tokens:

POST /setAuthToken — Set a new token (requires current valid token)
POST /resetAuthToken — Reset to the default token (requires current valid token)

Token changes take effect immediately; no server restart is required.

Available endpoints:

Endpoint	Description
`GET /`	Returns server information and a list of available endpoints.
`GET /health`	Health check. Returns server uptime, status, and start timestamp.
`GET /faissDbStatus`	Returns comprehensive database status: partition stats, memory usage, and configuration.
`POST /addFromCsv`	Loads events from a CSV file into the AFP database, partitioned by threat detector combination. Duplicates are filtered automatically.
`POST /cleanFaissDb`	Deletes all partitions and clears the entire database. This action is permanent and cannot be undone.

Example: Health check:

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"
}

/cleanFaissDb Cannot Be Undone

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

Performance Considerations

Application Fingerprinting is designed to operate efficiently within the Eyeglass appliance:

No Additional Hardware: Runs within existing appliance resources
Minimal Latency: Verification typically completes within milliseconds
Scalable Architecture: Handles high event volumes without degradation
Resource Efficiency: Low CPU and memory overhead

High Event Rate Environments

In environments with extremely high event rates (thousands of events per second), consider adjusting timeout parameters to balance verification thoroughness with event processing speed.

Customization and Operational Considerations

Application Fingerprinting can be tuned to match your organization's security requirements and operational environment.

Tuning Confidence Thresholds

The confidence threshold parameters control how aggressively Application Fingerprinting suppresses alerts.

Higher Threshold (More Strict)

Increasing thresholds (e.g., from 0.7 to 0.85) results in:

More Strict Detection: Only events with very high confidence scores are suppressed
More Alerts Generated: More events are raised to the security team
Lower Risk of Missing Threats: Reduces the chance of suppressing actual attacks
Higher False Positive Rate: More legitimate application activity generates alerts

Recommended For:

High-security environments
Compliance-driven organizations
Early deployment phases (conservative approach)
Environments with low baseline alert volume

Lower Threshold (More Aggressive)

Decreasing thresholds (e.g., from 0.7 to 0.6) results in:

More Aggressive Suppression: More events are classified as normal behavior
Fewer Alerts Generated: Significant reduction in alert volume
Higher Risk of Missing Threats: Increased chance of suppressing actual attacks
Lower False Positive Rate: Fewer legitimate activities generate alerts

Recommended For:

Mature deployments with well-established fingerprints
Environments with high false positive rates
Organizations with limited security team resources
Environments with well-understood application behavior

Monitoring and Adjustment Strategy

Initial Deployment: Start with default threshold values (0.7)
Observation Period: Monitor alert volume and Historical Alerts for 2-4 weeks
Analysis: Review suppressed events in Historical Alerts to identify:
- False negatives (actual threats being suppressed)
- False positives (legitimate activity generating alerts)
Threshold Adjustment: Incrementally adjust thresholds based on findings:
- If false negatives are detected: Increase thresholds by 0.05-0.10
- If false positive rate is too high: Decrease thresholds by 0.05-0.10
Iteration: Repeat analysis and adjustment cycle until optimal balance is achieved

Restart Requirements

Configuration Changes Require Service Restarts

Client configuration changes (data/system.xml): Require an SCA service restart
Server configuration changes (data/appfingerprinting/app_fingerprinting_config.json): Require sudo systemctl restart app-fingerprinting

Plan configuration changes during maintenance windows to minimize service disruption. Consider the following:

Backup Configuration: Always backup configuration files before making changes
Document Changes: Maintain a log of threshold adjustments and their impact
Staged Rollout: Test threshold changes in a non-production environment if possible
Rollback Plan: Be prepared to revert changes if unexpected behavior occurs

Example Configuration

The following examples demonstrate typical Application Fingerprinting configurations.

Client Configuration Example (system.xml)

<appfingerprinting>
    <!-- Enable the Application Fingerprinting feature -->
    <enableAppFingerprinting>true</enableAppFingerprinting>

    <!-- Confidence score threshold for event suppression -->
    <appFingerprintingTailThreshold>0.7</appFingerprintingTailThreshold>

    <!-- High confidence threshold for immediate suppression -->
    <appFingerprintingHigherThreshold>0.7</appFingerprintingHigherThreshold>

    <!-- Path similarity threshold -->
    <appFingerprintingPathsThreshold>0.7</appFingerprintingPathsThreshold>

    <!-- Timeout for pending verification (seconds) -->
    <appFingerprintingPendingTimerSec>120</appFingerprintingPendingTimerSec>

    <!-- Service connection timeout (seconds) -->
    <appFingerprintingServerConnectTimeoutSec>5</appFingerprintingServerConnectTimeoutSec>

    <!-- Service request timeout (seconds) -->
    <appFingerprintingServerRequestTimeoutSec>60</appFingerprintingServerRequestTimeoutSec>

    <!-- Service port -->
    <appFingerprintingServerPort>50000</appFingerprintingServerPort>
</appfingerprinting>

Server Configuration Example (app_fingerprinting_config.json)

The following example shows the default structure of the server configuration file (app_fingerprinting_config.json).

{
  "port": 50000,
  "blacklisted_threat_detectors": ["TD001", "TD005"]
}

Configuration Notes

Default Values: The examples above show typical production settings
Threshold Tuning: The 0.7 tail threshold provides balanced suppression
Timeouts: 60-second request timeouts accommodate most environments
Port Configuration: Default port 50000 rarely conflicts with other services
TD Exclusions: Empty by default; populate to exclude specific threat detectors

Minimal Configuration

For a minimal deployment, only the following client parameters are required in data/system.xml:

<appfingerprinting>
    <enableAppFingerprinting>true</enableAppFingerprinting>
    <appFingerprintingTailThreshold>0.7</appFingerprintingTailThreshold>
    <appFingerprintingServerPort>50000</appFingerprintingServerPort>
</appfingerprinting>

All other parameters will use system defaults if not explicitly specified.

Summary

Application Fingerprinting is a powerful feature that enhances Ransomware Defender's effectiveness by intelligently filtering false positive alerts while maintaining comprehensive security monitoring.

Key Benefits

Reduces False Positives: Automatically suppresses alerts from known safe application behavior, significantly reducing alert fatigue
Improves Detection Accuracy: Enables security teams to focus on genuine threats rather than investigating benign application activity
Provides Automated Suppression: Eliminates manual triage of repetitive false positives, improving operational efficiency
Maintains Complete Audit Trail: All events, including suppressed ones, are logged in Historical Alerts for compliance and analysis
Requires No Additional Infrastructure: Integrated directly into Eyeglass appliance with no additional hardware requirements
Scales Seamlessly: Handles high event volumes without performance degradation
Continuously Learns: Adapts to new application patterns over time, improving accuracy
Supports Multiple Languages: Uses multilingual model supporting over 50 languages

Operational Advantages

Reduced Alert Volume: Fewer alerts mean faster response times to actual threats
Lower Storage Consumption: Suppressed events do not trigger snapshot creation
Improved User Experience: Fewer false lockouts for legitimate users
Flexible Configuration: Tunable thresholds allow customization to your security posture
Enterprise Ready: Designed for high-security, compliance-driven environments

Getting Started

Application Fingerprinting is enabled by default in Eyeglass
If needed, verify or modify settings in /opt/superna/sca/data/system.xml
Start with default threshold values
Monitor Historical Alerts and active alerts for 2-4 weeks
Adjust thresholds based on your environment's characteristics
Iterate and refine for optimal performance

Application Fingerprinting represents a significant advancement in ransomware detection technology, providing intelligent automation that enhances security while reducing operational overhead.

Overview​

Purpose​

How Application Fingerprinting Works​

Event Detection and Verification Workflow​

Event Outcomes​

High Confidence Events (Known Application Behavior)​

Active Events (Partial or No Match)​

Manual Actions for Pending Events​

Pattern Learning​

Installation and Deployment​

Deployment Architecture​

System Files and Directories​

Configuration File Management​

Restart Requirements​

Enabling and Disabling Application Fingerprinting​

Enable Application Fingerprinting​

Disable Application Fingerprinting​

Configuration Options​

Client Configuration Parameters​

Server Configuration Parameters​

Server Configuration Example​

Parameter Impact and Tuning​

Confidence Thresholds​

Timeout Configuration​

Threat Detector Exclusions​

Operational Behavior and Impact​

Impact on Alert Processing​

Alert Volume​

Snapshot Creation​

User Lockout Behavior​

Historical Alert Storage​

Application Fingerprinting Learning Management​

Step 1: Confirm a Threat Analyzer File Is Available​

Step 2: Upload Events to the AFP Database​

Step 3: Monitor Progress via Log Tailing​

Step 4: Validate the Vector DB Was Created Successfully​

API Reference​

Performance Considerations​

Customization and Operational Considerations​

Tuning Confidence Thresholds​

Higher Threshold (More Strict)​

Lower Threshold (More Aggressive)​

Monitoring and Adjustment Strategy​

Restart Requirements​

Example Configuration​

Client Configuration Example (system.xml)​

Server Configuration Example (app_fingerprinting_config.json)​

Configuration Notes​

Minimal Configuration​

Summary​

Key Benefits​

Operational Advantages​

Getting Started​

Overview

Purpose

How Application Fingerprinting Works

Event Detection and Verification Workflow

Event Outcomes

High Confidence Events (Known Application Behavior)

Active Events (Partial or No Match)

Manual Actions for Pending Events

Pattern Learning

Installation and Deployment

Deployment Architecture

System Files and Directories

Configuration File Management

Restart Requirements

Enabling and Disabling Application Fingerprinting

Enable Application Fingerprinting

Disable Application Fingerprinting

Configuration Options

Client Configuration Parameters

Server Configuration Parameters

Server Configuration Example

Parameter Impact and Tuning

Confidence Thresholds

Timeout Configuration

Threat Detector Exclusions

Operational Behavior and Impact

Impact on Alert Processing

Alert Volume

Snapshot Creation

User Lockout Behavior

Historical Alert Storage

Application Fingerprinting Learning Management

Step 1: Confirm a Threat Analyzer File Is Available

Step 2: Upload Events to the AFP Database

Step 3: Monitor Progress via Log Tailing

Step 4: Validate the Vector DB Was Created Successfully

API Reference

Performance Considerations

Customization and Operational Considerations

Tuning Confidence Thresholds

Higher Threshold (More Strict)

Lower Threshold (More Aggressive)

Monitoring and Adjustment Strategy

Restart Requirements

Example Configuration

Client Configuration Example (system.xml)

Server Configuration Example (app_fingerprinting_config.json)

Configuration Notes

Minimal Configuration

Summary

Key Benefits

Operational Advantages

Getting Started