Home > Storage > ObjectScale and ECS > Product Documentation > ECS Cyber Protection Suite Reference Architecture > Ransomware Defender
At the core of the ECS cybersecurity framework is Ransomware Defender. The solution combines scalability with real-time event processing to detect and stop ransomware attacks. After detecting changes to users' normal system access patterns, Ransomware Defender can take defensive measures to prevent major damage and minimize recovery times when administrator-defined thresholds are met. If Ransomware Defender detects ransomware attack behavior, then multiple defensive measures, including disabling object users or IAM access keys, block all IO to object data within all S3 buckets the user has access to (either immediately or delayed with a count down), allowing administrators to cancel the lockout. Besides timed auto lockout rules, there is an automatic response escalation if multiple infections are detected simultaneously, even if an administrator is not available.
User behavior detection is based on known consistent ransomware access patterns early in the attack lifecycle, as shown in the following image. Historically, ransomware follows a specific pattern, as described in the section Ransomware lifecycle. Ransomware Defender monitors clusters for these specific events that are abnormal to typical user patterns. These include excessive encryption or movement of files that are not consistent with user behavior.
Ransomware Defender is accessed through Eyeglass, as shown in the following figure. Alerts, configuration, and status are all managed through Eyeglass. Administrators may already be familiar with Eyeglass for its extensive data replication and failover capabilities.
Ransomware Defender constantly monitors ECS clusters for specific activity that indicates a ransomware attack, using a fully automated learning mode to monitor behavior and avoid false positives. Further refining the detection, protection can be customized for more sensitive data. When a ransomware event is detected, access from the infected user’s account to ECS is blocked. As soon as ransomware activity has been detected and a user has been temporarily blocked, a notification is sent immediately to the administrator. Ransomware Defender only locks out the infected user, allowing other users to access the namespace and buckets.
Customers should enable bucket versioning on all S3 buckets even if the application does not need or use versions. When an active event occurs, Ransomware Defender displays the event state, severity, and other critical event information. In the following figure, users are locked out.
If an active event is detected, Ransomware Defender’s user behavior detection retains all associated security data.
Ransomware events are based on signal strength thresholds. The threat level and associated action are listed in the following table.
Threat Level | Ransomware Defender Action |
Warning | Eyeglass sends an email to notify any subscribed administrator(s) of the threat but takes no direct action. |
Major | Eyeglass begins a “delayed lockout” procedure. Notify the administrator(s) that a threat has been detected, and the user will be locked out after X minutes, unless the admin logs in and explicitly cancels the action. The grace period is configurable in Eyeglass settings. |
Critical | The user lockout is immediate, and the administrator(s) are notified. |
Administrators configure the threshold for detected ransomware events with an associated signal strength, interval, grace period, and an option to escalate the alerts based on the occurrence of events.
The threat detection Signal Strength measures the severity of the object active behavior. A higher count indicates a more severe detection. A Signal Strength column can be found in the Active Events or Event History tab of the Eyeglass Ransomware Defender window, as highlighted in the following figure.
Further, the signal strengths are based on specific threat detectors that contributed to the event, as shown in the following figure.
Note: The threat detectors are not documented for enhanced security and are for support only.
The Threshold menu also includes an option to Automatically learn from events in monitor state, allowing administrators to use events for learning the normal access patterns. The Critical on Mode option disables the automatic lockout feature for critical events and applies a major event delayed lockout. Furthermore, for each of the threshold levels, an event can be associated across multiple vectors, based on a combination of signal strength, interval, and duration, as shown in the following figure. The multiple vectors allow administrators to define varying combinations that could indicate an attack.
A critical part of security best practices is ensuring that threat detection systems are active and ready. Ransomware Defender includes a “Security Guard” feature, which simulates a ransomware attack to validate that all components are functioning, including alerting and lockout of user sessions. The feature can simulate an attack on demand or on a scheduled interval that may be required by regulatory security requirements. During the simulation, administrators are notified through the defined event thresholds. After the attack, a detailed log is available. The simulated attack includes options to define the user and specify the buckets, as shown in the following figure. This allows for further customization of the attack.
Honeypots are an important part of vulnerability management. It is essentially a “fake” object that mimics the original. The goal is that the hacker attacks the fake honeypot instead of the actual data, allowing the system to lock the user out early in the attack. Typically, a honeypot is used where sensitive data exists and allows for faster detection times at these locations in the system. Ransomware Defender allows honeypots in as many locations as needed.
The Zero Trust API is an add-on component to Ransomware Defender and enables integration with third party SIEMs and XDRs. A Security Information and Event Management System, or SIEM, facilitates the identifying and addressing of potential vulnerabilities and threats before they disrupt a company's operations. Using SIEM technology, event log data is collected from different sources, analyzed in real-time, and action is taken by Ransomware Defender if abnormal behavior is spotted. Depending on the security stack implementation, a SIEM may be sharing data with an XDR. However, the security stack implementation varies according to the environment.
An Extended Detection and Response (XDR) solution gathers and correlates data across multiple layers of security, including email, endpoint, server, cloud workload, and network. An XDR also collects data from other security systems, such as Endpoint Detection and Response (EDR), Network Detection and Response (NDR), SIEM, and other threat related data. Alternatively, some security implementations might have the EDR and NDR sharing data with the SIEM.
The Zero Trust API allows integration with XDRs and SIEMs, integrating with an organization’s security stack and further protecting ECS clusters. As a result, you can detect threats sooner, conduct investigations more quickly, and improve response times through security analysis. The integration provides a cohesive security approach across the corporate network by linking storage, network, endpoints, servers, and email domains using a bi-directional API, to bridge the security intelligence gap at the storage domain.
The bi-directional API security event analysis spans across detection vectors through the data, application, and network layers, as shown in the following figure. This allows the security system to identify suspicious activity quickly, because it can draw on data from multiple sources to identify potential threats. As a result, it can detect malicious activity earlier and take action to prevent it from escalating through the data center layers. For example, if a threat is detected from the security stack, this can be configured to trigger a user lockout across monitored ECS clusters.
The Security Infrastructure Stack now correlates data across domains and through the layers, allowing Ransomware Defender to monitor current threat levels.
The AirGap Enterprise module add-on to Ransomware Defender retains an offline copy of a dataset in an automated cyber vault. The offline dataset copy is logically segmented from the production network, providing two critical advantages. First, the dataset is stored in a secure offline vault, protecting it from enterprise network threats. A second advantage is planning for a ransomware attack that could cripple business operations. By using an offline dataset, you can quickly restore operations to the point in time when the last copy of the dataset was made, thus minimizing the impact and damage associated with the ransomware attack as a whole. Further, if a dataset is readily available to restore, payment of the ransom is not a consideration, potentially saving millions of dollars. The AirGap cyber vault also complies with the NIST cybersecurity framework best practices.
As part of the inside-the-vault hardened solution, full automation and in-band management allow access through a virtual machine within the cyber vault. The Smart Airgap technology ensures that data is only replicated when it is safe to do so. Further, the airgap mode provides a low-cost, fully automated solution.
Similar to the other modules in the ECS Cyber Protection Suite, you can access and manage the AirGap Agent through Eyeglass, as shown in the following figure.
Replication between the sites is controlled by Cyber Recovery Vault, which is completely protected from unauthorized access. Note that under normal operating conditions, the ECS Vault Cluster does not have network access outside of the Cyber Recovery Vault and stores the business continuity dataset. The Enterprise AirGap Agent performs data and security checks periodically, at a frequency defined by an administrator. All the data is transferred by the Airgap agent which includes the ECSSync jobs.
The AirGap Enterprise module runs through the following logical flow of steps, corresponding to the steps in Figure 17, to perform a security check and replicate changed data blocks: