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

Disclaimers for Data Security for Dell

Introduction​

This page contains general disclaimers about the scope of this Data Security (Ransomware Defender, Easy Auditor, Threat Hunting) documentation and known product and version limitations. It does not include the separate legal End User License Agreement (EULA), Support Services Agreement, or functional specification documentation that governs use of the product.

Documentation Scope​

This documentation covers the Data Security feature set as described in Superna's technical administration guides (threat detection tuning, thresholds, snapshots, filters, auditing, and Zero Trust API integration). It does not reproduce entitlement, warranty, indemnification, or support-contract terms from the separate EULA and Support Services Agreement documentation.

note

A separate EULA and Support Services Agreement governs license entitlement, patching and appliance modification policy, installation responsibilities, and day-to-day operational obligations for Data Security. Consult that agreement for support-contract and entitlement terms.

Data Security Is a Second Line of Defense​

Data Security assumes that malware has already circumvented other defenses before it reaches the storage layer. It is designed to complement — not replace — endpoint antivirus/antimalware, email and web security gateways, network IDS/IPS, and offline or immutable backup copies of critical data. Deploying Data Security without these other layers in place, or without offline/immutable backups, significantly reduces the overall protection a customer's environment receives.

Licensing Dependencies​

Data Security functionality is gated by license key, and features described in this documentation set may not be available on every deployment:

  • Each writable PowerScale or ECS cluster monitored by Ransomware Defender or Easy Auditor requires its own agent license and active maintenance, assigned through the Eyeglass License Manager. A cold/DR (non-writable) cluster can be monitored by the ECA without consuming an agent license.
  • The Zero Trust API's critical-path-snapshot and user-lockout/unlock endpoints require a separate Zero Trust API license key; read-only event endpoints do not.
  • Threat Hunting is included in your subscription license for Data Security Edition and requires a dedicated Machine Learning VM sized to the ECA cluster (see Design Guide).
  • Performance Auditor, when licensed, has its own minimum RAM requirement on the ECA.

Version Dependencies for Specific Features​

Several capabilities described in this documentation set depend on a minimum Ransomware Defender/Easy Auditor build or a minimum PowerScale OneFS/ECS release:

  • Multiplatform lockout/restore (running for a user's event across all configured platforms) and normalized, user-grouped event handling were introduced in release 2.9.0.
  • ECS object recovery and versioning support through Cyber Recovery Manager were introduced in release 2.9.0.
  • Learning mode for path-based noise reduction and learned thresholds was introduced in release 2.9.0.
  • HDFS licensing on the PowerScale cluster is no longer required for Data Security deployments (it remains a requirement for standalone Easy Auditor deployments storing the analytics database on PowerScale).

Confirm current release and licensing availability against the Release Notes and Pre-Requisites pages before relying on any specific feature in this documentation set.

Known Product Limitations​

The following limitations are documented in the source technical guides and should be accounted for when planning a deployment:

  • SMB shares created with variable expansion only support %U for automatic snapshot creation.
  • NFS lockout is supported but disabled by default, and requires IP-based license lists to lock out correctly; it must be explicitly enabled through the igls CLI.
  • The root user account on PowerScale cannot be locked out with a deny permission — see Root user access is a high security risk below.
  • File-extension filtering/blocking on SMB shares changes the audit events PowerScale generates, which can prevent Ransomware Defender from detecting activity on the filtered share — see File-extension filtering on SMB shares is a security risk below.
  • ECA cluster nodes must remain on the same Layer 2 subnet with low latency between nodes. Splitting a single ECA cluster's nodes across data centers is not supported — see Design Guide and ECA Deployment Options for supported multi-site topologies.

Root user access is a high security risk​

The root user should never be used to access data on PowerScale. Root has access to every share, even shares where access has not been explicitly granted to the root user. If a machine using the root user is compromised, that access could be used to encrypt or destroy data across the entire cluster.

The root user cannot be locked out with a deny permission — this is a hard platform constraint, not a configuration gap. Because of this, Ransomware Defender offers a separate protection mode, configured through the Eyeglass CLI, that disables the SMB protocol entirely on managed PowerScale clusters if a ransomware event is detected. This ensures a compromised machine using the root user cannot destroy all data on all clusters, since lockout alone cannot stop it.

danger

If any SMB share has run as root enabled, you are exposing that share's data to a very high security risk, because no lockout is possible for it. When a share has run as root enabled, the user SID sent to the storage platform is the root user's SID, not the actual Active Directory user's SID — so the system cannot distinguish or isolate the real user who triggered the detection.

Superna recommends removing run as root from all shares. Beyond the lockout limitation, run-as-root access fails PowerScale security audits under every major industry standard (PCI DSS, HIPAA, FedRAMP, ITSG, and others).

Before enabling the SMB-protocol-disable response mode, verify no shares have run as root enabled:

  1. Log in to Eyeglass and open Reports on Demand.
  2. Click Create New Report and wait for it to complete.
  3. Open the finished report (cancel any print dialog if one appears).
  4. Search the report for run_as_root.
  5. If any shares are found with this option set, do not enable the SMB-protocol-disable / lock-root feature until those shares are remediated.

File-extension filtering on SMB shares is a security risk​

PowerScale's native SMB share-level file-extension filtering/blocking changes the audit events the cluster generates for the filtered share. This means Ransomware Defender cannot detect activity on that share — no audit events are produced for the blocked extensions, so no detection and no alert is possible, regardless of how severe the activity is. This is true even though Ransomware Defender's primary detection vector is user behavior, not just file extensions — behavioral detection also depends on the underlying audit stream being complete.

Superna recommends using the Suspicious Extensions feature instead of native share-level extension blocking. Since release 2.5.7, each extension in the Suspicious Extensions list (see Detection Controls — Suspicious Extensions) can be set independently to Enabled (actively detected) or Disabled (present but not evaluated) — this gives finer-grained control than a native share-level block, without suppressing the audit visibility Ransomware Defender depends on.

Operational Responsibility​

Data Security's automated detection and response reduces — but does not eliminate — the operational responsibility of the customer's IT and security teams. Consistent with the product's design as a second line of defense, customers remain responsible for:

  • Keeping endpoint antivirus/antimalware, OS patching, and email/web security current across the environment.
  • Reviewing Data Security alerts, events, and Recovery Manager status in a timely manner rather than relying solely on automated lockout.
  • Maintaining an offline or immutable backup/vault copy of critical data, independent of Data Security's snapshot-based recovery.
  • Validating license counts and coverage for all writable clusters before onboarding, since Eyeglass raises an alarm — rather than blocking access — when writable clusters exceed licensed capacity.

See Also​