IBM Support

The Cumulative Benefits of IBM Power Cyber Vault for AIX, when Added to Traditional HA/DR

General Page

The following page provides detailed descriptions of each of the cumulative benefits of IBM Power Cyber Vault for AIX when added to Traditional High Availability and Disaster Recovery, assuming use of IBM PowerHA Enterprise Edition or IBM VM Recovery Manager DR for Power Systems. The benefits are listed based upon the initial tier they are made available. Since the benefits are cumulative, all benefits gained from a lower tier are carried over to all higher tiers.

Traditional HA/DR



Automatic Recovery of Hardware Failure

IBM PowerHA SystemMirror for AIX provides automated recovery from hardware failures by monitoring system resources and initiating failover actions to a standby node, typically within 30 to 300 seconds. It supports AIX environments by integrating with clustering technology to ensure application availability during unplanned hardware outages.

Key Mechanisms for Automatic Hardware Recovery:

  • Heartbeat Monitoring: PowerHA nodes continuously exchange "keepalive" packets (heartbeats). If a node stops sending these, PowerHA initiates failover of applications and resources to another node.


Common Failures Handled:

  • Disk Failures: Automatic actions can be taken for disk and disk adapter failures.
  • Node Outages: This includes kernel crashes, node reboots, and hung systems.
  • Network Failures: Detection of network interface failures and switching to backup adapters.


Additional information:



Automated Recovery of Site Failure

IBM VM Recovery Manager DR (VMRM DR) manages full site failures differently than local High Availability (HA). While the software automates the underlying orchestration, cross-site failovers require manual initiation by default to prevent split-brain scenarios and premature operations.

Unlike local HA, which automatically restarts virtual machines on adjacent local hardware, an entire site failure triggers a highly controlled workflow.

  • Automation of Orchestration: The solution automates storage replication control, network mapping, and VM profiles, completely removing human error from the technical execution.
  • Manual Trigger Safeguard: For cross-site recovery (planned or unplanned), an administrator must explicitly run the failover command after reviewing notification alerts. This avoids unintended failovers caused by transient network blips between data centers.
  • The IBM VM Recovery Manager controller (called the "KSYS") interfaces with the underlying storage vendor API (e.g., IBM, EMC, Hitachi) to make the target secondary replication devices read-write accessible.
  • The backup site hardware infrastructure boots the primary logical partitions (LPARs) using backed-up VM profiles.


Additional information:



Application Availability Monitored

In IBM PowerHA SystemMirror, tracking and managing application uptime revolves around Application Monitoring and the Application Availability Analysis Tool. These mechanisms ensure that applications defined to application controllers are actively monitored to eliminate them as single points of failure (SPOFs).

PowerHA uses two primary methods to verify that your critical workloads are running:

  1. Process Application Monitoring
    • Tracks the physical lifecycle of application processes using AIX's Reliable Scalable Cluster Technology (RSCT) and Resource Monitoring and Control (RMC).
    • Instantly detects process death or termination.
  2. Custom Application Monitoring
    • Runs a user-defined health-check script at specified polling intervals.
    • Tests actual functionality (e.g., sending a dummy transaction to a database or checking a port web response).


Additional information:



Standard RTO and RPO

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are key metrics in disaster recovery planning that define how quickly a business must recover from an outage and how much data it can afford to lose. RTO focuses on time (downtime limit), while RPO focuses on data loss volume (frequency of backups).

Recovery Time Objective (RTO)

  • Definition: The maximum acceptable time to restore business processes and IT systems after a disruption. It is measured in seconds, minutes, or hours, moving forward from the moment of failure.

Recovery Point Objective (RPO)

  • Definition: The maximum acceptable amount of data loss, measured in time, following an incident.
  • Focus: How much data can we afford to lose?


Additional information:

 

 


Tier 0



Reduced RTO Reduction Options

The Recovery Time Objective (RTO) is the amount of time it takes to recover data from a loss or corruption event. With tape backups, for example, this would be the time to:

  • Prepare the server to recover data onto it
  • Start the recovery process from the tape backup software.
  • Wait for the data to read from tape and be written to the server
  • Restart the server or application(s).


With Tape, this could take hours or sometimes even days. On the opposite side of the spectrum are snapshots, like this solution. The RTO can reduce minutes when reverting data to a snapshot:

  • Shutdown the server to be recovered
  • Recover the snapshot at the desired point-in-time
  • Restart the server


The Recovery Point Objective (RPO) is the worst case amount of time lost if you need to recover from the most recent backup. For example, you backup every night at 1 AM, and it takes 6 hours to complete. The backup on Monday morning completes and the server has a data corruption event on Tuesday morning at 6:30 AM, just before the backup was completed. You would need to revert to 1 AM Monday morning, so Recovery Point would be 29.5 hours ago.

The problem many backup methods is the amount of time to process. If the backup of the server takes 6 hours, the very minimum time between backups would need to be 6 hours, so the server would be continually doing a backup. Even with a continual backup, you could still only meet a 12 hour RPO assuming the most recent backup may not be complete. Snapshotting the volumes takes a few minutes, so having a snapshot every hour becomes an option and you can meet an RPO of 2 hours. This does need to be balanced with Storage Array limits and potential overhead from snapshotting too frequently.

The near-instant of HA is even better, but HA is almost always a synchronous copy of your data. So, while HA is about impossible to beat for physical server or site loss, it doesn’t hold up well with many corruption events. A near-instant failover to bad data doesn’t get you very far.

 

Recovery from Data Corruption Cyber Incidents using Immutable Backups

Safeguarded Copy (SGC) is IBM's immutable snapshot technology that creates point-in-time copies of storage volumes that cannot be modified. Unlike traditional snapshots or backups that can be corrupted, SGC provides protection by making a copy of the data that cannot be altered. An SGC is space efficient, only consuming the space needed to maintain the data on the volume as it was at the point-in-time that it was taken.

You cannot work with the data in the Safeguarded snapshot directly, you create a clone of the volume to work with the data from that point-in-time. Changes to the cloned volume do not affect the Safeguarded Snapshot, it is a one-way relationship from snapshot to clone. Even the complete overwriting of the volume that was protected by the Safeguarded copy, and a clone created from the Safeguarded snapshot, would not result in the data from that point-in-time or the ability to recover it to a new clone volume.

 

IBM Storage Insights Threat Detection1

IBM Storage Insights is a cloud-based storage monitoring and analytics platform that provides centralized visibility across IBM storage systems. In Cyber Vault, Storage Insights serves as the collection and forwarding point for FCM4 RTD alerts from FlashSystem and DS8000 storage. It receives threat alerts from FCM4 modules and correlates them with other storage events for a more comprehensive view. Storage Insights is required for FlashSystem deployments to enable FCM4 alert forwarding, but is optional (though recommended) for DS8000 deployments.

FlashCore Module (FCM4) is IBM's fourth-generation custom-designed solid-state drive technology that includes built-in real-time threat detection (RTD) capabilities. Unlike standard SSDs, FCM4 modules contain specialized hardware and firmware that analyze every block of data written to the drive in real time, looking for patterns and behaviors indicative of real-time threat activity. This hardware-level detection is designed to provide early warning of cyberattacks, often detecting threats before they can spread across your environment.

Unlike signature-based detection that requires known malware patterns, FCM4 uses behavioral analysis to detect threat activity patterns. This means it can detect zero-day threats and novel attack variants that have never been seen before, as long as they exhibit the statistical anomalies and behavioral patterns characteristic of modeled threat activity.

Integration of IBM Storage Insights with IBM Power Cyber Vault occurs during Tier 3 deployment.

For more information about IBM Storage Insights and FCM4, please see IBM Storage Insights Website or the Storage tab on our FAQ page

 

 


Tier 1



Customizable Policy-driven Recovery Automation using Red Hat Ansible Automation Platform

IBM Power Cyber Vault integrates Red Hat Ansible Automation Platform (AAP) to provide intelligent, policy-driven automation that transforms cyber recovery from a manual, error-prone process into a streamlined, repeatable operation. This integration enables organizations to orchestrate both proactive protection and reactive response workflows with precision and speed.

Ansible Automation Platform serves as the orchestration engine for IBM Power Cyber Vault, delivering enterprise-grade automation capabilities built on a solution trusted by thousands of organizations worldwide. Ansible's human-readable playbook format ensures that recovery procedures are documented as code, making them easy to review, test, and improve over time while meeting compliance requirements.

Cyber Vault Event-Driven Ansible (CVEDA) 
CVEDA is the reactive response component that automatically responds to security events detected by monitoring tools such as IBM Zero Trust Execution for AIX (ZTEA) or IBM FlashCopy Manager for Cyber Resiliency (FCM4). When a threat is detected, CVEDA immediately triggers customized Ansible playbooks that execute your organization's specific response procedures as defined in your Cyber Vault Response Policy (CVRP).

The event-driven architecture means that protective actions can begin immediately when threats are detected, dramatically reducing the time between detection and response. Instead of waiting for manual intervention to create safeguarded copies, your protection procedures execute automatically according to your pre-defined CVRP policies, ensuring that clean recovery points are captured before potential corruption spreads—even during off-hours or when key personnel are unavailable.

When the CVEDA receives a security event, it follows this workflow:

  1. A security monitoring tool (such as ZTEA or FCM4) detects a threat and generates an alert
  2. The alert is forwarded to CVEDA, which evaluates it against configured CVRP policies based on the workload's criticality level and the specific event type
  3. Based on the CVRP policy configuration, CVEDA triggers the appropriate Ansible playbook with the defined actions (protect, validate, notify, and in future versions, optionally recover)
  4. The playbook executes automated actions, such as initiating application-consistent Safeguarded Copies (SGC) for one or more virtual machines
  5. Validation processes identify clean versus potentially compromised copies from both scheduled and event-triggered safeguarded copies
  6. Notifications are sent to administrators with detailed information about the event, actions taken, and available recovery options
  7. In the current version, administrators review the validated options and make informed recovery decisions; in future versions, recovery may proceed automatically based on CVRP policy configuration


Cyber Vault Response Policy (CVRP) 
CVRP is the policy feature that defines how IBM Power Cyber Vault responds to both scheduled protection activities and security events. What makes this automation capability particularly powerful is the CVRP feature's flexibility and the granular control it provides. Organizations can define comprehensive response policies that match their unique business requirements, with different strategies based on workload criticality, business impact, and the type of security event detected.

The CVRP feature ensures you maintain full control over critical decisions while automating time-sensitive protective actions. Each CVRP policy can be customized to include any combination of response actions, with different configurations available depending on the tier of automation capability deployed.

The CVRP feature provides:

  • Policy as Code: Define and version-control your response policies alongside your infrastructure code
  • Audit Trail: Complete logging of all automated actions for compliance and forensic analysis
  • Testing and Validation: Test your CVRP policies in non-production environments before deploying to production
  • Continuous Improvement: Refine your policies based on real-world events and changing business requirements
  • Integration Flexibility: Extend CVRP policies to integrate with your existing security tools, ticketing systems, and communication platforms


Tier 1 Ansible Benefits: Proactive Protection
Tier 1 provides foundational automation capabilities focused on Proactive Protection. At this tier, Ansible automates scheduled, periodic creation of application-consistent Safeguarded Copies, ensuring you always have clean recovery points available.

Key Capabilities

  • Scheduled Safeguarded Copies: Automated creation of application-consistent backups according to defined schedules
  • Timeline of Recovery Points: Scheduled safeguarded copies run automatically, creating a timeline of known-good recovery points without manual intervention
  • Consistency and Reliability: Eliminates manual errors and ensures protection activities occur on schedule


Tier 1 is ideal for organizations that:

  • Need reliable, scheduled backup automation
  • Want to eliminate manual backup processes
  • Require consistent recovery point creation
  • Are establishing foundational cyber resilience capabilities


Tier 2 Ansible Benefits: Proactive Protection & Validation
Tier 2 extends Tier 1 capabilities by adding Proactive Validation. At this tier, organizations can validate their safeguarded copies to ensure they have clean, recoverable data.

All Tier 1 capabilities, plus:

  • Proactive Validation: Validate safeguarded copies to identify which are clean and recoverable
  • Recovery Readiness: Ensure backup integrity before a security event occurs
  • Visibility into Recovery Options: Clear understanding of available recovery points


Tier 2 is ideal for organizations that:

  • Need to verify backup integrity proactively
  • Want confidence in their recovery capabilities before an incident
  • Require validation of safeguarded copies on a regular basis
  • Need visibility into the health and recoverability of their backup data


Tier 3 Ansible Benefits: Reactive Response
Tier 3 represents the most advanced automation tier, adding Reactive Response capabilities through the full integration of CVEDA and CVRP. At this tier, when security events are detected, the system automatically responds with protection and validation actions, and can optionally automate the complete recovery process based on policy-defined criteria.

All Tier 1 and Tier 2 capabilities, plus:

  • CVRP Policies: Define comprehensive response policies based on workload criticality and event types
  • Full CVEDA Integration: Complete event-driven automation with customizable response workflows
  • Event-Driven Protection: Automatically create additional Safeguarded Copies when threats are detected
  • Reactive Validation: Automatically identify which copies are clean and which may be compromised in response to security events
  • Notification System: Alert security and operations teams with detailed event information and recovery options
  • Automated Recovery (Future Enhancement): Policy-driven automatic restoration from validated clean recovery points
  • Workload-Specific Policies: Different recovery behaviors based on system criticality, business impact, and downtime tolerance
  • Advanced Validation Requirements: Define criteria that must be met before automated recovery proceeds
  • Approval Workflows: Multi-level authorization for critical systems while allowing immediate recovery for lower-risk workloads


CVRP Actions Available in Tier 3

  • Protect: Automatically create additional application-consistent Safeguarded Copies to preserve clean recovery points before any potential corruption spreads
  • Validate: Automatically identify which copies are clean and which may be compromised, giving you clear visibility into your recovery options
  • Notify: Alert your security and operations teams immediately with detailed event information and available recovery options
  • Recover (Future Enhancement): Automatically restore systems from validated clean recovery points based on policy-defined criteria


Future CVRP Enhancement: Automated Recovery
A future version of IBM Power Cyber Vault may extend the CVRP feature to include automated recovery capabilities. This enhancement may allow organizations to define policies that automatically restore systems from validated clean recovery points when specific criteria are met.

This automated recovery capability may offer customization options within your CVRP policies, potentially enabling you to:

  • Define recovery triggers: Specify which types of security events should initiate automated recovery versus requiring manual approval
  • Set workload-specific policies: Configure different recovery behaviors based on system criticality, business impact, and downtime tolerance
  • Establish validation requirements: Define the criteria that must be met before automated recovery proceeds (e.g., successful validation of recovery point integrity, confirmation of threat containment)
  • Configure recovery parameters: Specify recovery point selection logic, rollback procedures, and post-recovery validation steps
  • Implement approval workflows: Require multi-level authorization for automated recovery of critical systems while allowing immediate recovery for lower-risk workloads


Future CVRP policies may include:

  • Development/Test Systems: Full automation including immediate recovery to minimize disruption to ongoing work
  • Non-Critical Production Systems: Automated recovery with post-recovery notification and validation
  • Business-Critical Systems: Automated protect and validate, with recovery requiring explicit approval from authorized personnel
  • Regulated Workloads: Enhanced validation and audit logging with mandatory approval workflows before any recovery action


This future enhancement is expected to maintain the core principle of organizational control while providing the flexibility to automate recovery where appropriate for your specific business needs and risk tolerance.

Typical Tier 3 Configuration
For production workloads, the typical CVRP configuration includes:

  • Protect: Automatically create additional application-consistent Safeguarded Copies to preserve clean recovery points before any potential corruption spreads
  • Validate: Automatically identify which copies are clean and which may be compromised, giving you clear visibility into your recovery options
  • Notify: Alert your security and operations teams immediately so they can make informed decisions about recovery timing and approach


This approach ensures that for your most critical business systems, human expertise and judgment remain in control of the final recovery decision. You get the speed and consistency of automated protection and analysis, while retaining the authority to decide when and how to restore production systems based on your business priorities, compliance requirements, and operational considerations.

Tier 3 is ideal for organizations that:

  • Need automated response to security events
  • Want to capture clean recovery points immediately when threats are detected
  • Require event-driven validation of backup integrity
  • Need to maintain human control over recovery decisions while automating protective actions
  • Want the fastest possible response times to security threats
  • Require sophisticated policy-based decision making for different workload types


For more information about IBM Power Cyber Vault automation capabilities and the CVARP feature, please see the Ansible Automation tab on our FAQ page
 

 

Automated Application-consistent Safe Guarded Copies

The FlashSystem has an internal scheduler that can be used to make Safeguarded snapshots of a Volume Group. For DS8000, CSM fulfills this capability of scheduling the snapshots. CSM provides some key advantages over the FlashSystem internal scheduler:

  • Application Consistent snapshots
  • More than 1 schedule for snapshots. This allows for scenarios like keeping hourly snapshots for 3 days and daily snapshots for 12 days.
  • The ability to coordinate snapshots with replication, or even with other snapshots in the environment.


The Application Consistency is not required for all applications, but startup of an application that was snapshotted as consistent is usually quicker and less likely to require intervention to bring it online. When a snapshot is not Application Consistent it is Crash Consistent. This would be like booting a server after it has experiences a loss of power. It could come online without any problems. It could come online slower as it checks filesystems and replays journals. Or, it could require the application administrator to work with it to fix any issues before it will come online.

 

 


Tier 2



Clean Room Isolated Data Integrity Testing

A clean room provides you the ability to validate the production environment without affecting the production environment. The validation process needs to scan the Safeguarded Snapshot Clone and this will consume Memory, CPU, VIO server resources, SAN bandwidth and I/O on the Storage Array. The clean room provides the ability to isolate that workload from the production workload. This can also provide a layer of isolation to work with the Safeguarded snapshot point-in-time clone without interaction with other servers in the environment to potentially limit malware propagation or re-infection from another compromised system.

 

Clean Room Proactive Validation Scheduled on a Daily, Weekly, or Custom Basis

Finding a clean copy of the server takes time when you are trying to recover from an issue. Spending the time to validate Safeguarded snapshots, stepping backwards through them, can be a slow process… especially when you have pressure to get the server back online.

Shifting the time to validate snapshots to happen throughout the day or week keeps the process well tested and running. It also means that if you have to recover from a snapshot, you have some idea of which snapshots are good to start with and most likely to work.

The validation process can even provide earlier detection. If a validation scan fails before the bad-actors make their move, you may be able to avoid the outage altogether.

 

 


Tier 3



Automated Recovery from Data Corruption Cyber Incidents

This solution provides the recovery capabilities of DR with near the speed of a HA solution.

When corruption occurs it is typical for the corruption to be replicated via HA up to the point that HA fails. HA is great for the business continuity response speed, but its goal is to keep the data synchronous between sites, so corruption can get through this layer of protection.

For recovering from lost or corrupted data, DR is the common choice in the industry, but backup solutions take time to backup and recover. As a result of this processing time, their RPO and RTO suffer.

With Safeguarded Snapshots, the data is protected to the point-in-time that it was taken, much like a DR backup. Taking and recovering snapshots is much quicker, closer to a HA failover, than a traditional recovery. This allows for RPO and RTO capabilities closer to HA with the data isolation and consistent point-in-time features of DR.

 

Real-time Reactive Validation Triggered by Security Events Detected on Monitored Endpoints

Scheduled validation is an amazing capability that can provide confidence in your Safeguarded snapshots. It still has a small area that can be improved upon though, the reliance on a schedule. If a snapshot as taken every 2 hours, and validated, you have good confidence and the ability to meet an RPO of 4 hours.

Let say that 1 hour after a snapshot is taken an incident occurs where data is massively corrupted. The current validation will not detect it until the next scheduled validation. With Storage Insights you will possibly know about the data loss event within minutes, but without manual intervention, the scheduled validation will not even start looking at the data loss event until nearly 1 hour after it occurred.

Integrating the Real-time Threat Detection (RTD) into this solution provides the ability to potentially start the validation immediately after a RTD is detected instead of waiting for the next scheduled event. The scheduled validations still occur to look for anything that RTD might not be able to detect, but validation can start as close to the RTD detection as possible.

 

Recover Quality Improved by Increased Speed and Immutable Backups Created Securely

The ability to recover in minutes from a snapshot that cannot be tampered with speaks for itself. This solution shoots reliability through the roof with immutability while pushing RTO down to a point that is really difficult to meet via cloning snapshots within a minute. A reduced RPO, due to the speed in which the snapshots can be taken, provides a tighter window for potential data loss.

There is even a possibility to have multiple Safeguarded snapshots taken throughout an active attack. This could be useful to law enforcement and auditors to forensically document the event. It cold even allow for data being processed during the attack to be manually extracted and imported back into a clean snapshot prior to the event. More snapshots can provide more options when an unfortunate event occurs.

 

Early Detection Minimizes Data Loss through SGCs Triggered by Security Event Detection

Taking an SGC as soon as a cyber incident is detected minimizes data loss mainly by capturing the most recent intact data before things get worse.

Cyber Vault allows you to take an SGC not just when a clearly obvious threat is detected, but also when a suspicious event is reported by a monitored endpoint.

In many attacks—like ransomware or unauthorized access—the damage often spreads over time. Files might be gradually encrypted, deleted, or altered. If you act quickly and take a backup early, you’re essentially freezing the system at a point where some or most of your data is still untouched. That gives you a much better recovery position than relying on an older backup that might already be days or weeks behind.

It also protects against continued attacker activity. If the breach is ongoing, the attacker could keep modifying or destroying data. A prompt backup ensures you’ve preserved a version of your data before further corruption or exfiltration happens.

Another angle is operational continuity. Even if the compromised system has to be taken offline for investigation, that immediate backup lets you restore recent business data elsewhere, reducing disruption and avoiding the need to recreate lost work.

The important nuance is that this backup isn’t automatically “clean.” It may still contain compromised elements. But from a data-loss perspective, it preserves the latest available state of legitimate data, which you can later filter, validate, and safely restore.

When a security risk is detected, the risk is reported with the following workflow:

  1. The alert generated by PowerSC, FMC4, or ZTEA code gets forwarded to the PowerSC GUI Server
  2. Depending upon the PowerSC GUI Server configuration, the PowerSC GUI Server will processes the alert and forward it to the CVEDA
  3. Depending on the policy configuration of the CVRP, the CVEDA may respond to the event and begin an SGC for one or more VMs

 

For more information about PowerSC, FCM4, and ZTEA, please see our FAQ page

 

Threat Detection with PowerSC

IBM PowerSC, commonly referred to as "PowerSC", is IBM's official security offering for Power. It provides numerous security measures for protecting AIX, IBM i, Linux on Power, HMC, VIOS, and Linux on Intel.

The PowerSC GUI Server is the centralized server that provides monitoring and configuration of security measures deployed on PowerSC managed endpoints.

For AIX, PowerSC provides numerous types of security measures that can be deployed on AIX endpoints: 

  1. Security & Compliance Automation (Security Hardening)
  2. Native File Integrity Monitoring with Real-Time Compliance or AIX Trusted Execution
  3. Allowlisting with AIX Trusted Execution
  4. Native AIX patching with Trusted Network Connect & Patch Management
  5. Host Intrusion Detection measures
  6. Malware Defense with ClamAV and Blocklisting


Depending upon the PowerSC GUI Server configuration, the PowerSC GUI Server can also receive security alerts from IBM Storage Insights.

The PowerSC Custom Event feature allows non-PowerSC tools to have a degree of semi-integration with PowerSC. If a non-PowerSC tool implements PowerSC Custom Event support using REST API programming, it will allow the tool to report its security events to the PowerSC GUI Server using PowerSC's security alerting configuration options and functions. 

ZTEA is able to report the security events that it detects to the PowerSC GUI Server using PowerSC's Custom Event feature.  

When these security measures are deployed on AIX endpoints, they allow PowerSC to detect potential or active threats. This threat detection can then be used by Cyber Vault to trigger an SGC on one or more VMs.

All of the security measures described above enable PowerSC to provide threat detection on monitored endpoints.  Depending upon the PowerSC GUI Server configuration, an event may be reported to the CVEDA or a SIEM. The CVEDA will respond to the event by initiating an SGC on one or more endpoints, depending upon how the CVRP is defined for the endpoint that reported the event.

For more information about PowerSC, see the PowerSC tab on our FAQ page, or PowerSC Documentation

 

Hardware and Firmware-based Threat Detection with FCM4

FlashCore Module (FCM4) is IBM's fourth-generation custom-designed solid-state drive technology that includes built-in real-time threat detection (RTD) capabilities. Unlike standard SSDs, FCM4 modules contain specialized hardware and firmware that analyze every block of data written to the drive in real time, looking for patterns and behaviors indicative of real-time threat activity. This hardware-level detection is designed to provide early warning of cyberattacks, often detecting threats before they can spread across your environment.

Unlike signature-based detection that requires known malware patterns, FCM4 uses behavioral analysis to detect threat activity patterns. This means it can detect zero-day threats and novel attack variants that have never been seen before, as long as they exhibit the statistical anomalies and behavioral patterns characteristic of modeled threat activity.

IBM Storage Insights is a cloud-based storage monitoring and analytics platform that provides centralized visibility across IBM storage systems. In Cyber Vault, Storage Insights serves as the collection and forwarding point for FCM4 RTD alerts from FlashSystem and DS8000 storage. It receives threat alerts from FCM4 modules and correlates them with other storage events for a more comprehensive view. Storage Insights is required for FlashSystem deployments to enable FCM4 alert forwarding, but is optional (though recommended) for DS8000 deployments.

When FCM4 detects threat activity, it generates a threat alert that follows this workflow:

  1. The FCM4 alerts the FlashSystem or DS8000 and an alert gets forwarded to the PowerSC GUI Server
  2. Depending upon the PowerSC GUI Server configuration, the PowerSC GUI Server will processes the alert and forward it to the CVEDA
  3. Depending on the policy configuration of the CVRP, the CVEDA may respond to the event and begin an SGC for one or more VMs.


FCM4 and ZTEA use completely different methods for detecting malware, so if malware is not detected by one of the defenses, the other defense may be able to detect the malware. Using FCM4 and ZTEA simultaneously for malware defense is known as a defense-in-depth strategy. Defense-in-depth strategy is a cyber security practice of using multiple layers of defense, so if one layer of defense is defeated by an attacker, there is one or more additional layers that still provide defense.

For more information about FCM4, please see the Storage tab on our FAQ page

 

Threat Detection with IBM Zero Trust Execution for AIX

IBM Zero Trust Execution for AIX® (ZTEA) is a real time malware defense for AIX that uses a Zero Trust approach. ZTEA is designed to detect, and optionally prevent, the execution of all types of software-based malware (including ransomware, zero-day malware, next-generation malware, hacking tools, exploitation software, polymorphic malware, viruses, root kits, worms, and trojans).

ZTEA uses a combination of up to three different malware defenses to mitigate malware risk. The 3 defenses are:

  1. Allowlisting - provided by AIX Trusted Execution
  2. Malware signatures - provided by ClamAV
  3. Hashing - provided by ZTEA


In addition to detecting malware execution in real time, ZTEA uses allowlisting for detection of execution of potential threats such as deleted, altered, and new executables in real time. 

When ZTEA detects threat activity, it generates a security alert that follows this workflow:

  1. On the endpoint AIX host, ZTEA generates a REST API call to the PowerSC GUI Server that details the event
  2. Depending upon on the PowerSC GUI Server configuration, the event may be forwarded to the CVEDA.
  3. Depending on the policy configuration of the CVRP, the CVEDA may respond to the event and begin an SGC for one or more VMs.

 

FCM4 and ZTEA use completely different methods for detecting malware, so if malware is not detected by one of the defenses, the other defense may be able to detect the malware. Using FCM4 and ZTEA simultaneously for malware defense is known as a defense-in-depth strategy. Defense-in-depth strategy is a cyber security practice of using multiple layers of defense, so if one layer of defense is defeated by an attacker, there is one or more additional layers that still provide defense.

For more information about ZTEA, please see the ZTEA tab on our FAQ page or the ZTEA Website


 


Footnotes & References

  1. IBM Storage Insights is available in Tier 0. Integration with IBM Power Cyber Vault occurs during Tier 3 deployment

 

[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SSB2BD2","label":"IBM PowerSC"},"ARM Category":[{"code":"a8m3p000000UoK7AAK","label":"PowerSC Multi-factor Authentication (PMFA)"},{"code":"a8m3p000000UoK2AAK","label":"PowerSC Standard (PSC)"}],"Platform":[{"code":"PF002","label":"AIX"}],"Version":"2.0.0;2.1.0;2.2.0;2.3.0"}]

Document Information

Modified date:
12 May 2026

UID

ibm17271687