Skip to main content
Version: 2.14.0

What's New in 2.14.0

Version 2.14.0 introduces significant improvements to Ransomware Defender, focusing on reducing alert fatigue and improving the accuracy of ransomware detection through intelligent application behavior learning.

Application Fingerprinting​

Application Fingerprinting is a new feature that identifies normal application behavior patterns and automatically suppresses alerts that match known safe behavior. This capability addresses one of the most critical challenges faced by storage administrators: alert fatigue caused by repeated false positives.

Key Benefits:

  • Reduced Alert Fatigue: Automatically suppress alerts from known safe application behavior
  • Improved Detection Accuracy: Focus on genuine threats rather than false positives
  • Quick Results: Leverage existing false positive data from Threat Analyzer to deliver immediate value after upgrade
  • Maintained Protection: Continue protecting against ransomware while reducing noise
  • Seamless Integration: Works with existing GUI and APIs for an improved user experience

Application Fingerprinting Learning Management​

Application Fingerprinting is designed to deliver rapid time-to-value by leveraging existing data already collected in Threat Analyzer. This enables quick results after upgrading to version 2.14.0.

Post-Upgrade Recommendation: Upload Historical Events

To maximize the effectiveness of Application Fingerprinting, upload historical events to the AFP database after upgrading. This step ensures AFP can learn from your past environment and deliver more accurate results faster.

  • Manually upload historical events using the process described below
  • Optionally filter out events you do not want included before uploading

This step is especially important because:

  • It accelerates the 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 improves detection accuracy sooner. For the exact steps, see Application Fingerprinting Learning Management.

Getting Started with Application Fingerprinting​

To begin using Application Fingerprinting in version 2.14.0:

  1. Upgrade to 2.14.0: Ensure your system is running version 2.14.0 or later
  2. Review Threat Analyzer Data: Existing data will be leveraged in your learning
  3. Upload Historical Events (Recommended): Manually upload past events to accelerate learning
  4. Monitor Results: Observe the reduction in alert volume while maintaining protection

See also​

For full details on configuration and behavior, see Application Fingerprinting.

Alarm Batching​

Alarm Batching consolidates multiple alarm notifications into periodic batch emails, reducing alert fatigue while maintaining critical alert visibility through intelligent bypass mechanisms.

Instead of sending each alarm individually, Eyeglass collects alarms over a configurable time window and sends them together in a single summary email. The batch window defaults to 5 minutes but can be set anywhere between 60 and 3600 seconds. A maximum batch size (10–500 alarms) can also be configured — when reached, the batch is sent immediately regardless of the window.

Enabling / Disabling

igls adv alertbatching set --enabled=true
igls adv alertbatching set --enabled=false

Disabling flushes any pending batches immediately and resumes per-alarm delivery.

Configuring the Batch Window and Max Size

igls adv alertbatching set --window=900      # seconds (60–3600)
igls adv alertbatching set --max-size=150    # alarms per batch (10–500)

Bypass Mechanisms

Some alarms require immediate delivery and cannot wait for a batch. Three bypass options are available:

  • Global Critical Bypass — all alarms with CRITICAL severity bypass batching and are sent immediately. 
    igls adv alertbatching set --critical-bypass=true
  • Unconditional Bypass List — specific alarm codes always bypass batching, regardless of severity. 
    igls adv alertbatching add --code=SCA0004
  • Critical-Only Bypass List — specific alarm codes bypass batching only when their severity is CRITICAL. 
    igls adv alertbatching add --code=SCA0123 --critical-only=true

Bypass codes can be removed individually or cleared in bulk:

igls adv alertbatching delete --code=SCA0004
igls adv alertbatching delete --code=SCA0123 --critical-only=true
igls adv alertbatching delete --type=bypass --all=true
igls adv alertbatching delete --type=criticalbypass --all=true

Viewing Full Status

igls adv alertbatching

The output includes global enabled/disabled status, current configuration settings, bypass code lists, and statistics (batches sent, alarms batched, bypass count, and reduction percentage since last restart).

See also​

For full details on configuration and behavior, see Alarm Batching.

PowerScale Cluster FQDN Support​

When adding a PowerScale cluster to the appliance, you can now specify a Fully Qualified Domain Name (FQDN) instead of a PowerScale IP address. This recommended configuration enables SmartConnect load balancing.

If a node becomes unavailable, SmartConnect directs the connection to another node, providing more resilient access to the cluster.

Auto-Loading of Licenses​

Starting with version 2.14, Eyeglass accepts licenses with a future start date without failing. Because the start date has not yet arrived, the granted values remain inactive. Eyeglass moves the license to a pending folder, which it checks each night at midnight (UTC). When the start date arrives, Eyeglass loads the license automatically.

This behavior benefits renewal licenses that start at midnight — you can load the license any time after receiving it and do not need to wait for the exact start time.

Need Help?​

  • Contact Support: Reach out to Superna Support for configuration assistance or troubleshooting help