General Page
FAQ Categories
A: IBM Power Cyber Vault is a comprehensive cyber resiliency solution for IBM Power Systems that automates the creation, validation, and recovery of immutable backup copies in an isolated clean room environment. It helps organizations detect ransomware faster, minimize damage, and recover confidently from cyber incidents.
Q-g2: How is cyber resiliency different from cyber security?
A: Cyber security focuses on defending and protecting - keeping bad actors out of your environment. Cyber resiliency focuses on anticipating cyber incidents and ensuring your organization’s ability to continue operations and rapidly recover if a cyber incident does occur. Organizations need both - security to prevent attacks and resiliency to anticipate and recover when prevention fails.
Q-g3: Why do I need this if I already have backups?
A: Traditional backups can be compromised for days, weeks or months before detection. IBM Power Cyber Vault continuously validates your backups in an isolated environment, ensuring you always know which copies are clean and recoverable. It’s insurance for your insurance.
Q-g4: Which industries benefit most from this solution?
A: Industries with mission-critical IBM Power workloads and high downtime costs:
- Financial services (banking, insurance, payments)
- Healthcare (hospitals, health systems)
- Government (federal, state, local)
- Manufacturing (critical infrastructure)
- Retail (large-scale operations) - Energy & utilities
Q-g5: What is the “clean room” concept?
A: The clean room is an isolated IBM Power environment where SafeGuarded Copies are recovered and validated without risk to production systems. It is air-gapped from production networks as a best practice, allowing safe testing and forensic analysis of potentially compromised data.
Q-g6: What are the solution tiers?
A: IBM Power Cyber Vault offers 4 tiers:
Tier 0: Storage controller-level SafeGuarded Copy creation (basic entry point)
Tier 1: Automated application-consistent SafeGuarded Copies via Copy Services Manager
Tier 2: Tier 1 + scheduled proactive validation in clean room environment
Tier 3: Tier 2 + reactive validation triggered by security events (PowerSC, ZTEA, Storage Insights)
Q-g7: What validation checks are performed?
A: Three types of integrity checks:
- Type 1: IPL (Initial Program Load) and OS validation - ensures system boots properly
- Type 2: Data structure validation - verifies database and application structures
- Type 3: Data content validation - checks actual customer data integrity and consistency
Q-g8: Can I customize the validation process?
A: Yes, validation can be customized for:
- Application-specific checks (database consistency, transaction logs, etc.)
- Business logic validation
- Custom scripts and tests
- Industry-specific compliance requirements
Q-g9: How does reactive validation work?
A: In Tier 3, security tools (PowerSC, ZTEA, Storage Insights) monitor for threats in real-time. When a security event is detected, depending upon the CVRP, the system automatically:
1. Creates an immediate out-of-cycle SafeGuarded Copy
2. Triggers validation in the clean room
3. Reports findings to administrators
4. Enables rapid response and recovery
Q-g10: Who performs the implementation?
A: IBM Expert Labs performs the implementation. Prerequisites (Ansible, CSM, PowerSC) can be installed by Expert Labs, the customer, or a Business Partner.
Q-g11: What is the Solution Workshop?
A: A 1-day IBM-funded engagement where an IBM Expert Labs consultant will:
- Assess your current cyber resilience strategy
- Review IBM Power and Storage infrastructure
- Identify critical workloads and requirements
- Present IBM Power Cyber Vault solution
- Create implementation roadmap and proposal
Deliverables: Cyber resiliency readiness report, proposed architecture, gap analysis, deployment plan
Q-g12: Can we implement in phases?
A: Yes, the tiered approach is designed for phased implementation:
- Start with Tier 0 for immediate protection
- Implement Tier 1 for automated application consistent workload protection
- Add Tier 2 when ready for validation capabilities
- Expand to Tier 3 for advanced threat response
- Scale across additional workloads over time
Q-g13: What if we don’t have all prerequisites?
A: The workshop identifies gaps and creates an action plan. Missing components can be:
- Procured and installed by the customer
- Installed by IBM Expert Labs
- Installed by an IBM Business Partner
Implementation begins once prerequisites are in place.
Q-g14: What are the hardware requirements?
A: Core components:
- Source IBM Power servers - Your existing production systems
- IBM Storage - FlashSystems or DS8K with SafeGuarded Copy capability
- Clean room IBM Power servers - For validation (Tier 2+), sized to host validation LPARs
Q-g15: What are the software requirements?
A: Required software (incremental):
Tier 0:
- IBM Copy Services Manager v6.3.10+
Tier 1:
- Red Hat Ansible Automation Platform v2.5+ (with Automation Hub, EDA, Redis)
Tier 2:
- Additional LPAR capacity for clean room
Tier 3:
- IBM PowerSC v2.2.0.5+
- IBM Storage Insights (for FlashSystems)
- IBM Zero Trust Execution for AIX (ZTEA) - optional for AIX
Q-g16: How much storage capacity is needed?
A: Storage requirements depend on:
- Number of critical workloads protected
- Size of each workload
- Number of SafeGuarded Copies retained, and for how long
- Data change rate
Q-g17: How often are SafeGuarded Copies created?
A: SGC frequency is customizable based on your RPO requirements. Common schedules:
- Every 4 hours (6 copies per day)
- Every 6 hours (4 copies per day)
- Every 8 hours (3 copies per day)
- Every 24 hours (1 copies per day)
- Custom schedules for different workload tiers
Q-g18: How often are validation tests performed?
A: Validation frequency is configurable:
- Proactive (Tier 2): Daily, weekly, or custom schedule
- Reactive (Tier 3): Triggered automatically by security events
– On-demand: Manual validation when needed
Q-g19: What happens when corruption is detected?
A: When validation identifies a corrupted copy, IBM Power Cyber Vault:
1. Marks the SGC as infected
2. Alerts administrators via configured channels
3. Provides the ability to test previous SGCs, not already validated, to find clean copy
4. Provides forensic data for analysis
5. Recommends newest clean copy for recovery
Q-g20: How is the solution monitored?
A: Monitoring capabilities include:
- SGC creation success/failure tracking
- Validation test results (pass/fail)
– Security event notifications
- Integration with SIEM solutions
- Email/SMS alerts for critical events
Q-g21: Can we test recovery without impacting production?
A: Yes, that’s the purpose of the cleanroom. You can:
- Recover any SGC to the clean room
- Perform full validation testing
- Run application-level tests
- Conduct forensic analysis
All without any risk to production systems
Q-g22: How long does recovery take?
A: Recovery time depends on:
- Data volume size
- Storage performance
- Application startup time
- Validation time
Typical recovery times: 30 minutes to 4 hours for most workloads. The solution helps meet aggressive RTO requirements by eliminating investigation time - you know which backup is clean before starting recovery.
Q-g23: How is the solution priced?
A: Pricing is based on the solution tier selected (0, 1, 2, or 3), the number of workloads protected, the IBM Storage and Power capacity required and the IBM Expert Labs professional services for implementation. Contact IBM Expert Labs or your brand seller for detailed pricing.
Q-g24: What is included in the IBM Expert Labs price?
A: Typical engagement includes:
- Solution Workshop (IBM investment)
- Solution design and architecture
- Implementation by IBM Expert Labs
- Delivery, configuration, and testing of Ansible automation playbooks and workflows
- Knowledge transfer and training
- Documentation and runbooks
- Post-implementation support period
Q-g25: Can we start small and expand?
A: Yes, the solution is designed for scalability
Q-g26: What is the ROI?
A: ROI factors include:
- Cost avoidance: ransomware payments, extended downtime
- Reduced recovery time: 50-70% improvement typical
- Operational efficiency: automated validation vs. manual testing
- Compliance: avoid audit findings and penalties
- Risk reduction: lower cyber insurance premiums
Most customers achieve ROI by avoiding a single major incident.
Q-g27: How do we get started?
A: Getting started is easy:
1. Contact your IBM Expert Labs or IBM Power/Storage representative
2. Request a Solution Workshop
3. Complete the 1-day assessment
4. Review proposed solution and pricing
5. Approve and schedule implementation
6. Begin phased deployment
For IBM personnel, contact: Slack: #expert-labs-resiliency-practice
Q-g28: What makes IBM Power Cyber Vault different from competitors?
A: Key differentiators:
- Purpose-built for IBM Power environments
- Automated validation vs. manual or no testing
- Validation customization using tailored playbooks, scripts, etc
- Integrated platform vs. multiple-point solutions
- Cyber resiliency is enhanced by being able to better anticipate cyber incidents by leveraging PowerSC's cyber security event detection
- IBM Expert Labs implementation expertise
Q-g29: Can this work with non-IBM storage?
A: IBM Power Cyber Vault is optimized for IBM Storage (FlashSystems and DS8K) due to SafeGuarded Copy capabilities. For non-IBM storage, alternative approaches may be available - consult with IBM Expert Labs.
Q-g30: What about cloud integration?
A: The current solution is on-premises focused.
Q-g31: How does this work with existing DR solutions?
A: IBM Power Cyber Vault complements existing DR:
- Adds cyber resiliency to DR strategy
- Validates DR or remote copies are clean
- Provides additional recovery points
- Enhances overall resilience posture
– Can integrate with DR orchestration
Q-a1: What is Ansible Automation Platform and how does it help with IBM Power Cyber Vault?
A: Ansible Automation Platform is Red Hat's enterprise automation software that orchestrates IBM Power Cyber Vault's protection and recovery operations. It automatically responds to security threats by creating secure backup copies of your critical systems and validating they can be recovered. The platform provides a web interface for management, secure credential storage, job scheduling, and detailed audit logs for compliance. When a security threat is detected, Ansible coordinates all the technical steps needed to protect your data without manual intervention, reducing response time from hours to seconds and ensuring consistent, reliable protection.
Q-a2: Which version of Ansible Automation Platform should we deploy?
A: IBM Power Cyber Vault supports both version 2.5 and 2.6. Version 2.6 is recommended for new deployments because it offers better real-time security response capabilities and improved performance. If you're already using version 2.5, it works well with all core features and can be upgraded to 2.6 when convenient. Both versions provide the enterprise reliability and scalability needed for production environments.
Q-a3: Why is the full Ansible Automation Platform required instead of open-source Ansible?
A: While open-source Ansible can run the core automation, the full platform is essential for production environments. It provides a centralized web interface for operations, enterprise-grade security for credentials, comprehensive audit trails for compliance, automated job scheduling, and the ability to respond automatically to security events. These features reduce operational overhead, improve security posture, and ensure accountability. The platform investment is offset by reduced manual work and faster incident response.
Q-a4: What is Event-Driven Automation and why is it important for Cyber Vault?
A: Event-Driven Automation automatically triggers protective actions when security threats are detected, without waiting for human intervention. Traditional approaches require security teams to detect threats, assess them, and manually start protection procedures, which can take minutes to hours. Event-Driven Automation eliminates this delay by continuously monitoring for security events and immediately executing protection workflows. When PowerSC detects threats like unauthorized file changes or suspicious activity, the system instantly creates secure backup copies. This is critical because cyber attacks can spread through systems in seconds, making manual response too slow. The automation provides 24/7 protection and frees security teams to focus on threat analysis rather than operational tasks.
Q-a5: What is a rulebook and how does it work in Cyber Vault?
A: A rulebook is a configuration file that defines how the system responds to different security events. It specifies which events to monitor, what conditions trigger actions, and which protection workflows to execute. For example, a rulebook might specify that when PowerSC reports a file integrity violation or a malware execution on a critical system, the system should immediately create a secure backup and test its recoverability. Rulebooks use the Cyber Vault Response Policy to ensure responses match system importance levels, providing consistent and auditable security responses.
Q-a6: What is the Cyber Vault Response Policy and how does it align with business priorities?
A: The Cyber Vault Response Policy is a tiered framework that determines how the system responds to security events based on system importance. Mission-critical production systems get immediate automated protection and validation when threats are detected. Standard production systems receive automated protection with scheduled validation checks. Non-production systems have events logged for review with optional manual action. This approach focuses protection resources on the most important business systems while maintaining visibility across the entire environment. Organizations can customize the policy to match their specific risk management and compliance requirements.
Q-a7: How does Ansible receive security alerts from PowerSC?
A: PowerSC forwards security alerts to Ansible Automation Platform Event-Driven Automation using two communication methods: rsyslog (a standard logging protocol for reliable message delivery) and webhook (real-time web-based messaging). PowerSC acts as a central collection point, gathering security events from multiple tools like ZTEA (Zero Trust Endpoint Assurance, which monitors endpoint security) and other security components. PowerSC evaluates these events, filters out noise, and forwards actionable alerts to Ansible Event-Driven Automation, which then orchestrates the appropriate protective response based on threat severity and system importance.
Q-a8: How does Ansible integrate with IBM storage systems?
A: Ansible communicates with IBM Copy Services Manager through a secure web interface to perform storage operations. It creates safeguarded copies using FlashCopy technology (which takes instant snapshots with minimal performance impact), creates thin clones for testing recovery procedures, maps storage volumes to recovery systems, and monitors operation status. All operations include error handling and retry logic to ensure reliability. This integration enables rapid protection of large datasets with minimal storage overhead and provides detailed logs for compliance reporting.
Q-a9: How does Ansible manage IBM Power Systems hardware?
A: Ansible integrates with the Hardware Management Console through a secure web interface to manage system operations. It can power systems on and off, activate system configurations, manage connections for validation testing, check system status, and retrieve hardware information. This integration is essential for validation workflows, where Ansible automatically sets up recovery systems in an isolated test environment, connects protected storage, and performs automated recovery testing without affecting production systems. This eliminates manual steps and ensures consistent testing procedures.
Q-a10: Can security tools other than PowerSC trigger Cyber Vault workflows?
A: Yes, third-party security tools can integrate through multiple approaches. The recommended method is using PowerSC's Custom Event feature, which provides a standardized integration point and maintains PowerSC as the central security event platform. Alternatively, security tools that support webhook, rsyslog, or Redis can directly integrate with Ansible Event-Driven Automation, though this requires custom configuration and event formatting. Organizations should evaluate integration approaches based on their security architecture and operational capabilities. IBM can provide integration guidance for common security tools.
Q-a11: Can Ansible integrate with our Security Information and Event Management (SIEM) platform?
A: Integration with Security Information and Event Management systems is planned for a future release. This will enable Cyber Vault to send workflow results and operational alerts to your central security monitoring system using standard protocols. Your security team will be able to see Cyber Vault events alongside other security events, providing comprehensive visibility and enabling better threat detection through event correlation. Organizations planning SIEM integration should engage with IBM to influence requirements and participate in early access programs.
Q-a12: What are the primary workflows that Ansible orchestrates?
A: Ansible orchestrates three core workflows. The Protect Workflow creates application-consistent backup copies by coordinating with applications to ensure data consistency, triggering storage snapshot operations, and storing tracking metadata. This directly supports recovery point objectives (how much data you can afford to lose). The Validate Workflow verifies recovery readiness by locating existing backups, creating test copies, mapping them to recovery systems in an isolated environment, and performing automated validation tests. This supports recovery time objectives (how quickly you need to recover) and provides documented evidence for compliance. The Recovery Workflow, planned for a future release, will coordinate actual disaster recovery including system startup, recovery script execution, and application validation.
Q-a13: What triggers automated protection workflows?
A: Protection workflows are triggered three ways. Security event-driven protection responds to real-time threats detected by PowerSC, providing immediate protection when systems are under attack. Scheduled protection runs at defined intervals (daily, weekly, or custom) to ensure baseline protection independent of security events, supporting recovery objectives and compliance requirements. Manual execution allows administrators to create on-demand protection for testing, pre-maintenance snapshots, or compliance audits. This multi-trigger approach ensures protection occurs both reactively to threats and proactively according to business continuity requirements.
Q-a14: What's the difference between Protect and Validate workflows?
A: Protect creates new immutable backup copies of production systems by coordinating with applications to ensure data consistency, then using storage technology to create secure snapshots that cannot be modified or deleted. This process doesn't impact production system availability. Validate verifies that existing backups are actually recoverable by creating temporary test copies, mapping them to recovery systems in an isolated environment, and performing automated recovery tests. Validate doesn't create new backups, doesn't modify the protected copies, and doesn't affect production operations. Organizations should perform Protect operations based on how much data they can afford to lose and Validate operations based on how quickly they need to recover and compliance requirements.
Q-a15: How does Ansible ensure database backups are application-consistent?
A: Ansible implements application-specific procedures to ensure database backups are consistent and recoverable. For Oracle databases, it places tablespaces in hot backup mode, creates the backup, then returns the database to normal operation while ensuring transaction logs are consistent. This allows backups without database downtime. For Db2 databases, it temporarily suspends input/output operations, flushes data from memory to disk, creates the backup, then resumes normal operations. For file systems, it synchronizes data buffers and creates consistent snapshots. These procedures ensure that restored databases will be in a consistent, usable state without corruption or data loss.
Q-a16: What are thin clones and what business value do they provide?
A: Thin clones are space-efficient copies of backups used for validation testing. Unlike traditional full copies that duplicate all data, thin clones initially use very little storage and only consume additional space as data changes during testing. They're created almost instantly using copy-on-write technology. This provides significant value through reduced storage costs (enabling frequent validation without massive storage investments), faster validation cycles, risk mitigation (testing recovery without risking production data), and compliance support (enabling regular recovery testing required by many regulations). Thin clones are used in isolated test environments, allowing realistic recovery testing including application startup and validation.
Q-a17: How does Ansible handle workflow failures and ensure reliability?
A: Ansible implements comprehensive error handling to ensure reliability. For temporary problems like network timeouts, the system automatically retries operations with configurable delays. For critical errors, automatic rollback procedures restore systems to their pre-workflow state, reversing any application changes and cleaning up partial operations. Failed workflows trigger notifications through multiple channels (email, webhooks, monitoring platforms) ensuring appropriate teams are immediately aware. Detailed error logs are captured for troubleshooting, and failure information is stored for trend analysis. This ensures workflow failures don't create additional business risk and provides the visibility needed for maintaining high availability.
Q-a18: Can Ansible protect multiple systems concurrently and how does this scale?
A: Yes, Ansible Automation Platform supports parallel workflow execution, which is critical for protecting large environments within acceptable time windows. A properly sized controller can handle 20-50 concurrent jobs depending on resources. For larger environments, the platform supports horizontal scaling by adding more controller nodes to the cluster, and workloads can be distributed across multiple controllers. This ensures protection operations can complete within maintenance windows even for environments with hundreds of systems. Organizations should size infrastructure based on the number of systems requiring protection, desired protection frequency, and acceptable protection window duration.
Q-a19: What is Redis and why is it critical for Cyber Vault operations?
A: Redis is an in-memory data store that serves as the system's memory and communication hub. It stores workflow information including backup identifiers, timestamps, system configurations, and application-specific details required for recovery point selection. It also provides event streaming capabilities for distributing security events and maintains workflow execution state for coordination. From a business perspective, Redis enables intelligent recovery point selection by maintaining complete protection history, supports compliance reporting through comprehensive audit trails, and enables capacity planning through trend analysis. Redis should be deployed with data persistence enabled and in high-availability configurations for production environments.
Q-a20: What is the business impact if Redis becomes unavailable?
A: Redis unavailability impacts operational capabilities but doesn't prevent core protection workflows from completing. New workflows can't store metadata in Redis, event streaming is disrupted, and protection history becomes temporarily inaccessible. However, Ansible Automation Platform maintains independent job history and execution logs, so workflows can complete and recovery point identification remains possible. To mitigate this risk, organizations should deploy Redis with high availability configurations, implement data persistence, maintain regular backups, and configure Ansible to retry Redis connections. Redis should be treated as critical infrastructure with appropriate availability targets and monitoring.
Q-a21: How does the system track protection history and support compliance?
A: Ansible stores comprehensive workflow information in Redis including backup identifiers, session information, timestamps, system configurations, workflow results, and application-specific details. This detailed tracking enables intelligent recovery point selection based on business requirements, supports automated retention policy enforcement, provides complete audit trails for regulatory compliance, facilitates troubleshooting and root cause analysis, and enables trend analysis and capacity planning. Organizations can export this data for integration with compliance management platforms and use it to demonstrate recovery capability during audits.
Q-a22: How are credentials and secrets managed securely?
A: Ansible Automation Platform provides enterprise-grade credential management. All credentials are encrypted at rest using AES-256 encryption (military-grade encryption) with keys managed by the platform's secret management system. Credentials are never stored in automation scripts or version control systems. The platform supports multiple credential types including storage system credentials, server credentials, hardware management credentials, and database credentials. At runtime, credentials are securely injected into workflows, sensitive data is automatically masked in logs, access is controlled through role-based permissions, and credential rotation is supported without requiring script modifications. This approach supports compliance with security frameworks and reduces the risk of credential compromise.
Q-a23: What monitoring and reporting capabilities support operations and compliance?
A: Ansible Automation Platform provides comprehensive monitoring through workflow execution dashboards showing real-time job status, success and failure metrics, execution time tracking, and resource utilization. Complete job history provides audit trails of all workflow executions with detailed logs, timestamps, and user attribution that are searchable and filterable. Configurable notifications alert administrators of job success, failure, or warnings through multiple channels including email, webhooks, and messaging platforms. Combined with Redis data, the system generates protection coverage reports, tracks recovery point objectives, monitors validation frequency and success rates, and analyzes capacity utilization trends. These capabilities support operational management, compliance reporting, and continuous improvement.
Q-a24: How does scheduled protection work and how should it be configured?
A: Ansible Automation Platform includes job scheduling capabilities that enable automated protection aligned with business continuity requirements. Schedules can be configured for specific times (e.g., daily at 2:00 AM), regular intervals (e.g., every 6 hours), complex patterns using cron expressions (a standard scheduling format), or specific days of the week or month. Multiple schedules can be configured for different system tiers, aligning protection frequency with business importance and recovery objectives. Schedules can be temporarily disabled for maintenance, and execution history is tracked for compliance. Scheduled protection operates independently of event-driven protection, ensuring baseline protection even without security incidents. Organizations should configure schedules based on recovery objectives, system importance, storage capacity, and compliance requirements.
Q-a25: Can workflows be customized for specific organizational requirements?
A: Yes, all Cyber Vault automation components are fully customizable. Customization options include modifying workflow logic and task sequences, adding custom procedures for specific applications, adjusting event conditions and response actions, configuring environment-specific parameters, and customizing job templates. However, customizations should maintain core architecture for supportability, be thoroughly documented, be tested in non-production environments first, be version controlled, and follow automation best practices. Common customizations include additional application-specific procedures, custom validation tests, integration with enterprise monitoring platforms, modified response policies for specific security events, and custom reporting workflows. Organizations should balance customization with maintainability and supportability considerations.
Q-a26: What are the deployment requirements for Ansible Automation Platform?
A: Deploying Ansible Automation Platform requires several components. Licensing includes Ansible Automation Platform 2.5 or 2.6 subscription, sufficient licenses for all managed systems, and Red Hat Enterprise Linux subscriptions for platform nodes. Infrastructure includes Red Hat Enterprise Linux 9 servers with minimum 4 CPU cores and 16 GB RAM per controller node (more for larger environments), a PostgreSQL database for data persistence, and a Redis instance for Cyber Vault metadata. Network connectivity includes access to managed systems, Hardware Management Console, Copy Services Manager, and Redis with appropriate firewall rules. Storage includes sufficient disk space for database and logs, persistent storage for Redis data, and container image storage. Skills requirements include automation development and troubleshooting, platform administration, IBM Power Systems administration, storage management, and Event-Driven Automation concepts. Organizations should conduct capacity planning based on environment size, protection frequency, and growth projections.
A: 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.
Q-s2: What is a FlashCore Module (FCM4)?
A: FlashCore Module (FCM4) is IBM's fourth-generation custom-designed solid-state drive technology that includes built-in real-time threat detection 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 provides extremely early warning of cyberattacks, often detecting threats before they can spread across your environment.
Q-s3: What about newer FlashCore Modules (FCM5/FCM6)?
A: The FCM5 modules have been announced with additional RTD metrics, Quantum Safe Encryption, Deduplication, Exfiltration and Wiperware detection. There is no public information on the FCM6 modules in development yet, but they build on the existing capabilities to provide enhanced protection for your data.
Q-s4: What is IBM Copy Services Manager?
A: IBM Copy Services Manager (CSM) is a storage management application that provides centralized orchestration of storage copy operations across IBM FlashSystem and DS8000 storage systems. In Power Cyber Vault, CSM serves as the control point for all storage operations, including creating SGCs, assigning volumes (mapping / masking) to LPARs, and coordinating recovery operations. Ansible Automation Platform communicates with CSM via REST API to automate all storage-related workflows. CSM is a required component for all Power Cyber Vault tiers.
Q-s5: How does Ansible integrate with IBM CSM?
A: Ansible Automation Platform integrates with IBM CSM through CSM's REST API. Ansible playbooks and roles make API calls to CSM to perform storage operations such as: 1) Authenticating to CSM and managing sessions, 2) Creating SGCs of production volumes, 3) Creating thin-clone recoveries from SGCs for validation, 4) Mapping recovery volumes to clean-room or production LPARs, 5) Unmapping volumes after validation or recovery, 6) Querying SGC status and metadata. All CSM operations are orchestrated through Ansible workflows, providing automated, repeatable storage operations. (For more information about Ansible workflows, see Ansible tab: Q-a8, Q-a26)
Q-s6: What is IBM Storage Insights and how is it used in Cyber Vault?
A: 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.
Q-s7: What is a storage volume in the context of Cyber Vault?
A: A storage volume (LUN / vdisk) is a logical unit of storage space within a storage array that appears to the Power server as a disk drive. In Cyber Vault, there are Production and Recovery storage volumes. Production volumes contain your active data and applications on the server to be protected. These volumes are protected by creating SGCs at scheduled intervals or in response to security events. Recovery volumes are separate volumes, generally mapped to another server, used to restore SGCs for validation or production recovery.
Q-s8: What is a thin-clone recovery and how is it used in Cyber Vault?
A: This is the IBM FlashSystem method of a recovery volume. A thin-clone recovery is a space-efficient, writable copy of a SGC. When Cyber Vault needs to validate a SGC in a clean-room LPAR, Ansible uses CSM to create a thin-clone recovery from the SGC. The thin-clone recovery can be mounted to a clean-room LPAR for validation testing without consuming the full storage capacity of the original data and without modifying the immutable SGC. Thin-clone recoveries use copy-on-write technology, so they only consume storage space for blocks that are modified during validation. After validation completes, the thin-clone recovery is deleted, leaving the original SGC intact.
Q-s9: What is a Dedicated Recovery Volume and how is it used in Cyber Vault?
A: This is the IBM DS8000 method of a recovery volume. A standard writeable storage volume, not thin, that is reserved for recovering the SGC point-in-time. When Cyber Vault needs to validate a SGC in a clean-room LPAR, Ansible uses CSM to recover the data from the SGC onto the dedicated recovery volume. The dedicated recovery can be mounted to a clean-room LPAR for validation without modifying the immutable SGC. After validation completes, the dedicated recovery remains ready for use in the next recovery and validation.
Q-s10: Can I use Cyber Vault with non-IBM storage systems?
A: No. IBM Power Cyber Vault requires IBM FlashSystem or IBM DS8000 storage systems because the solution depends on IBM-specific technologies including SGC and FlashCore Module (FCM4) Real-Time Threat Detection (RTD). These capabilities are not available on non-IBM storage systems. Organizations with non-IBM storage will need to migrate to IBM FlashSystem or DS8000 to implement Cyber Vault.
Q-s11: What storage systems are supported in IBM Power Cyber Vault?
A: IBM Power Cyber Vault supports two enterprise storage platforms: IBM FlashSystem and IBM DS8000. Both systems provide the cyber-resiliency features leveraged by Cyber Vault, including SGCs, and FlashCore Module (FCM4) RTD capabilities.
Q-s12: Are there minimum storage system requirements for Cyber Vault?
A: Yes. IBM Power Cyber Vault utilizes IBM FlashSystem or DS8000 storage systems with specific feature codes and firmware levels that support SGC and FlashCore Module (FCM4) RTD. Not all FlashSystem and DS8000 models or configurations support these features. The IBM Power Cyber Vault Workshop assesses your current storage infrastructure and identifies whether your existing systems meet requirements or if upgrades are needed. Contact your IBM storage representative for specific model and feature code requirements.
Q-s13: Where can I learn more about IBM FlashSystem and DS8000?
A: For detailed information about IBM storage systems, visit the IBM Storage product pages:
- IBM FlashSystem Product Information
- IBM DS8000 Product Information
Q-s14: What is the difference between IBM FlashSystem and IBM DS8000 for Cyber Vault?
A: Both FlashSystem and DS8000 provide the same core features required for cyber resiliency, including SGC and FCM4 . RTD FlashSystem is a storage system optimized for high performance with sub-millisecond latency and is available in models ranging from entry-level to extreme high-end configurations. DS8000 is IBM's flagship enterprise storage system designed for mission-critical workloads requiring maximum reliability, availability, and serviceability. The choice between them depends on your performance requirements, capacity needs, existing infrastructure, and budget. Both integrate with Cyber Vault automation workflows. There are differences in the protection mechanisms for SGC between DS8000 and FlashSystem. FlashSystem does the expiration internally and does not allow early expiration. DS8000 uses CSM to do it’s expiration and allows early SGC expiration within customer defined protected limits.
Q-s15: Do I need to replace my existing storage to implement Cyber Vault?
A: Not necessarily. If you already have IBM FlashSystem or DS8000 storage with the appropriate licensing, you may be able to use your existing infrastructure. However, older storage models or non-IBM storage systems will need to be upgraded or replaced. The IBM Power Cyber Vault Workshop assesses your current storage infrastructure and provides recommendations for meeting Cyber Vault requirements.
Q-s16: What is the role of storage in IBM Power Cyber Vault?
A: Storage is a foundational component of Cyber Vault that provides three critical capabilities:
1. Immutable data protection through SGCs that cannot be altered
2. RTD at the hardware level using FlashCore Module (FCM4) technology
3. Rapid recovery capabilities by maintaining multiple point-in-time copies that can be validated and restored to production systems.
Q-s17: How does storage high availability work in Cyber Vault?
A: Storage high availability in Cyber Vault is provided through multiple mechanisms:
1. IBM FlashSystem and DS8000 systems include redundant controllers, power supplies, and internal components for hardware-level high availability
2. Fibre Channel multipathing provides redundant paths between Power servers and storage
3. SGCs are protected by the storage system's RAID and redundancy features
4. Multiple SGCs throughout the day ensure multiple recovery points are available
5. Optional storage replication to a secondary system provides site-level protection. The specific high availability architecture is designed during the Cyber Vault workshop based on your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements.
Q-s18: How does storage participate in the four phases of Cyber Vault (Identify, Protect, Detect, Recover)?
A: Storage plays a role in all four phases: 1) Identify - During the workshop phase, storage capacity, performance requirements, and architecture are assessed and designed, 2) Protect – SGCs are created on a schedule or triggered by security events, 3) Detect - FCM4 RTD analyzes every block written to storage in real time for malicious patterns and forwards alerts to the PowerSC GUI Server, 4) Recover - SGCs are restored to recovery volumes, validated in clean-room LPARs, and used to recover production systems from verified clean snapshots.
Q-s19: How are SGCs created in Cyber Vault?
A: SGCs are created through two methods: 1) Scheduled protection - Ansible Automation Platform orchestrates the creation of, optionally, application-consistent SGCs at defined intervals (hourly, daily, etc.) based on your RPO requirements, 2) Reactive protection - Security events detected by the PowerSC GUI Server, ZTEA, or FCM4 RTD automatically trigger Ansible workflows to create immediate SGCs, capturing a clean recovery point before potential corruption spreads. (For more information about automation workflows, see Ansible tab: Q-a9, Q-a12, Q-a13, Q-a14, Q-a24)
Q-s20: What is the retention period for an SGC?
A: The retention period for SGCs is configurable based on your organization's recovery requirements and compliance needs. Typical retention periods range from 7 days to 15 days or longer. The retention period is defined during the Cyber Vault design workshop and can be customized per application or workload. Once set, the retention period is enforced by the storage system and cannot be shortened, even by administrators, until the period expires.
Q-s21: Do SGCs replace my need for backups?
A: SGCs are not intended to replace traditional backups. They are designed to provide a point-in-time recovery option for critical applications and workloads with an extremely low recovery time. SGCs are retained for a more limited period of time, and often for a critical subset of the environment. Traditional backups, on the other hand, are typically retained for longer periods to provide a complete history of your data, and are cover the environment as a whole. It is important to have both SGCs and traditional backups in place to ensure data protection and recovery.
Q-s22: What is the difference between SGC and traditional backup solutions?
A: Traditional backup solutions typically copy data to separate backup media (tape, disk, cloud) and therefore have a higher RPO while lacking immutability. SGC creates immutable snapshots directly on the storage system that cannot be altered. Key differences include:
1. Speed - SGCs are created in seconds using storage-level snapshots, while traditional backups can take hours
2. Immutability - SGCs cannot be modified, while traditional backups can be corrupted
3. Integration - SGCs integrate directly with Power Cyber Vault automation for rapid validation and recovery
4. Granularity - Multiple SGCs can be created throughout the day with minimal performance impact.
Q-s23: How many SGCs can I maintain?
A: The number of SGCs you can maintain depends on your storage type, storage capacity, snapshot frequency, and data change rate. The FlashSystem is currently limited to 255 SGCs per volume while the recent DS8000s support 1024. For example, if you create hourly snapshots with a 10-day retention period, you would maintain up to 240 snapshots per volume. The actual storage capacity required depends on how much data changes between snapshots—only changed blocks consume additional space. Capacity planning is performed during the IBM Power Cyber Vault Workshop to ensure adequate storage is provisioned for your protection requirements.
Q-s24: How do I access data from an SGC?
A: SGCs cannot be directly accessed or mounted—they must first be restored to a recovery volume. In Power Cyber Vault, this process is automated by Ansible workflows. When validation or recovery is needed, Ansible uses IBM CSM to restore the SGC to a recovery volume, which is then mapped to a clean-room LPAR for validation or to production LPARs for recovery. This restore process does not modify or consume the original SGC. (For more information, see the Ansible tab)
Q-s25: How does FCM4 Real-Time Threat Detection work?
A: FCM4 RTD analyzes multiple statistical indicators in real time as data is written to the storage system. There are dozens of metrics tracked on each volume, but for example, detection algorithms examine:
1. Compression anomalies - Ransomware-encrypted data typically has poor compression ratios compared to normal data
2. Encrypted payload patterns - Detection of encryption-like data patterns that differ from normal application encryption
3) Unusual read/write behavior - Abnormal access patterns such as sequential rewrites of large amounts of data
4) Block-access sequencing abnormalities - Unusual patterns in how data blocks are accessed and modified. When multiple indicators align, FCM4 generates a threat alert that is forwarded to IBM Storage Insights and the PowerSC GUI Server for automated response.
Q-s26: Is FCM4 RTD available on both FlashSystem and DS8000?
A: Yes. Both IBM FlashSystem and IBM DS8000 support FlashCore Module (FCM4) technology with real-time threat detection capabilities. This provides consistent threat detection capabilities regardless of which storage platform you choose for your Cyber Vault implementation.
Q-s27: What happens when FCM4 RTD detects a potential threat?
A: When FCM4 detects suspicious 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. The PowerSC GUI Server processes the alert and forwards it to the Cyber Vault Event Driven Automation (CVEDA) component
3. Ansible evaluates the alert against the Cyber Vault Response Policy (CVRP) and automatically triggers appropriate protection workflows, typically creating an immediate SGC to capture a clean recovery point. (For more information about event processing, see the PowerSC and Ansible tabs)
Q-s28: Does FCM4 RTD prevent threats from executing?
A: No. FCM4 RTD is a detection technology, not a prevention technology. It identifies suspicious storage activity patterns that may indicate threats, but it does not block or prevent the activity. Instead, it provides extremely early warning that enables automated response through Cyber Vault workflows. Prevention capabilities are provided by other Cyber Vault components such as ZTEA (which can prevent malware execution on AIX) and PowerSC security measures. (For more information, see ZTEA tab)
Q-s29: Can FCM4 RTD detect zero-day threats that have never been seen before?
A: Yes. 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.
Q-s30: Can FCM4 and ZTEA be used together to mitigate malware risk?
A: Yes. FCM4 and ZTEA use completely different methods for mitigating malware risk, so if malware circumvents detection by one of the defenses, the other defense may be able to detect the malware. Using both FCM4 and ZTEA malware defense is known as defense-in-depth. Defense-in-depth 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.
Q-s31: Does FCM4 RTD impact storage performance?
A: No. FCM4 RTD is performed by specialized hardware within the FlashCore Module itself, using dedicated processing resources that do not impact the data path or storage performance. The analysis happens inline as data is written, with no measurable performance penalty to applications or workloads.
Q-s32: How does storage integrate with PowerSC in Cyber Vault?
A: Storage integrates with PowerSC GUI Server through the FCM4 RTD event flow. When FCM4 detects suspicious activity, the alert is forwarded to the PowerSC GUI Server. The PowerSC GUI Server receives these storage-based threat alerts and processes them using its event management capabilities. The PowerSC GUI Server can then forward the alerts to the CVEDA controller to trigger automated protection workflows based on the CVRP. This integration enables storage-detected threats to automatically trigger protective actions. (For more information about PowerSC event processing, see PowerSC tab)
Q-s33: How are storage volumes mapped to clean-room LPARs for validation?
A: Storage volume mapping for validation is orchestrated by Ansible through IBM CSM. The workflow is:
1. Ansible identifies which SGC needs validation
2. Ansible instructs CSM to create a thin clone or restore the SGC to a recovery volume
3. Ansible instructs CSM to map the recovery volume to the designated clean-room LPAR
4. The clean-room LPAR can now access the volume and perform validation tests
5. After validation completes, Ansible instructs CSM to unmap the volume and delete the thin clone if used.
This entire process is automated and does not require manual storage administration. (For more information about validation workflows, see the Ansible tab)
Q-s34: What storage events are currently supported by the CVRP?
A: The CVRP currently supports FCM4 RTD events from both IBM FlashSystem and IBM DS8000 storage systems. When FCM4 detects suspicious activity patterns indicative of threats, these alerts are processed through the CVRP to determine the appropriate automated response based on the affected LPAR's criticality tier (production mission-critical, production standard, or non-production).
Q-s35: How are application-consistent SGCs created?
A: Application-consistent SGCs are created through Ansible orchestration that coordinates application quiesce operations with storage snapshot creation. For database workloads, Ansible executes pre-snapshot scripts that place the database in a consistent state (such as Oracle hot backup mode), then instructs IBM CSM to create the SGC, then executes post-snapshot scripts to return the database to normal operation. This ensures the SGC contains a consistent, recoverable state of the application. The quiesce and snapshot operations are coordinated to minimize application impact, typically completing in seconds. (For more information about application-consistent backups, see the Ansible Tab)
Q-s36: Are SGCs required to be application-consistent?
A: SGCs are not required to be application-consistent. The application-consistent backup feature is optional and can be enabled or disabled based on your organization's requirements. If enabled, application-consistent SGCs are created using Ansible orchestration to ensure the backup is consistent with the application at the time of the snapshot. If disabled, crash-consistent SGCs are created. Many environments work well with crash-consistency through the application design to handle this gracefully. For those that don't handle crash consistency well, like In-Memory Databases such as SAP HANA, the application-consistency feature provides integrity via minor overhead. (For more information about application-consistent backups, see the Ansible tab)
Q-s37: What is the difference between scheduled and reactive SGCs?
A: Scheduled SGCs are created at predefined intervals (hourly, daily, etc.) based on your RPO requirements, regardless of whether any security events have occurred. These provide regular recovery points for normal operations. Reactive SGCs are created immediately in response to security events detected by the PowerSC GUI Server, ZTEA, or FCM4 RTD. When a potential threat is detected, Ansible automatically triggers an immediate SGC to capture a clean recovery point before the threat can spread. (For more information about protection workflows, see the Ansible tab)
Q-s38: How long does it take to create a SGC?
A: Creating a SGC typically takes only seconds to complete. The actual time depends on the storage system's snapshot technology and the size of the volume, but modern IBM FlashSystem and DS8000 systems use pointer-based snapshot technology that creates the snapshot almost instantaneously. The application quiesce operations (if required for application consistency) may add a few additional seconds.
Q-s39: Can I create SGCs of multiple volumes simultaneously?
A: Yes. Ansible Automation Platform supports parallel workflow execution, allowing simultaneous creation of SGCs across multiple volumes and LPARs. This is essential for enterprise environments where many systems need coordinated protection during security events. IBM CSM can orchestrate multiple snapshot operations concurrently, and Ansible can trigger protection workflows for multiple LPARs in parallel based on the CVRP. (For more information about parallel workflows, see the Ansible tab)
Q-s40: How do I recover production systems from a SGC?
A: Production recovery from a SGC follows a validated workflow:
1. The SGC has already been validated in a clean-room LPAR and marked as clean
2. The production LPAR is shut down (if still running)
3. Ansible orchestrates the recovery by instructing CSM to restore the validated SGC to production recovery volumes
4. The recovery volumes are mapped to the production LPAR, replacing the potentially corrupted production volumes
5. The production LPAR is booted from the recovery volumes
6) Post-recovery validation confirms successful recovery
This process is semi-automated, with Ansible coordinating the steps and providing guidance to administrators. (For more information about recovery workflows, see the Ansible Tab)
Q-s41: What happens to the original production volumes during recovery?
A: During recovery, the original production volumes (which may be corrupted or encrypted by threats) are unmapped from the production LPAR and replaced with recovery volumes containing the validated SGC. The original production volumes are not immediately deleted—they are retained for forensic analysis to understand the attack vector and extent of compromise. After forensic analysis is complete and recovery is confirmed successful, the original volumes can be deleted.
Q-s42: Does creating SGCs impact production performance?
A: Creating SGCs has minimal impact on production performance. IBM FlashSystem and DS8000 use pointer-based snapshot technology that creates snapshots almost instantaneously without copying data. The performance impact is typically limited to:
1. Brief application quiesce operations (seconds) if application-consistent snapshots are required
2. Minimal I/O overhead for the snapshot metadata operations
3. Potential slight performance impact on subsequent writes to blocks that are part of a snapshot (copy-on-write overhead). In practice, most applications experience no noticeable performance impact from SGC creation, especially when snapshots are scheduled during lower-activity periods.
Q-s43: Can I use my existing Fibre Channel infrastructure for Cyber Vault?
A: Yes, if your existing Fibre Channel infrastructure meets the requirements for IBM FlashSystem or DS8000 connectivity. Your FC switches, HBAs, and fabric must support the appropriate protocols and speeds for your chosen storage platform. The IBM Power Cyber Vault Workshop assesses your existing infrastructure and identifies any upgrades or modifications needed to support Cyber Vault requirements.
Q-s44: What storage licensing is required for Cyber Vault?
A: Storage licensing requirements depend on your chosen platform and features:
1. IBM DS8000 requires licenses for SGC (Copy Services Function Group)
2. IBM DS8000 requires licenses for RTD (Security Function Group)
3. IBM CSM requires appropriate licensing for your storage platform
Storage licensing is separate from IBM Power Cyber Vault services and must be acquired through your IBM storage representative. Detailed licensing requirements are identified during the Cyber Vault design workshop.
Q-s45: Can I use Cyber Vault storage for other purposes besides SGCs?
A: Yes. IBM FlashSystem and DS8000 storage systems used for Cyber Vault can also host regular production volumes and other storage workloads. The storage capacity is shared between production volumes, SGC capacity, and recovery volumes. However, it's important to properly size the storage system to ensure adequate capacity and performance for all workloads. The IBM Power Cyber Vault Workshop includes comprehensive capacity planning to ensure your storage infrastructure can support both Cyber Vault requirements and other storage needs.
Q-s46: How does Cyber Vault storage integrate with SIEM systems?
A: Storage events from Cyber Vault, can be forwarded to Security Information and Event Management (SIEM) systems for centralized security monitoring. The common event flow is: FCM4 alert → FlashSystem or DS8000 → Storage Insights → PowerSC GUI Server → SIEM (via syslog, webhook, or API). This integration enables correlation of storage-based threat detection with other security events across your enterprise. Ansible can be configured to forward workflow results and storage events to your SIEM system. (For more information about SIEM integration, see the ansible tab)
Q-s47: What forensic analysis capabilities does Cyber Vault storage provide?
A: Cyber Vault storage enables forensic analysis through several mechanisms:
1. SGCs preserve the exact state of data at specific points in time, allowing forensic teams to analyze when corruption or encryption occurred
2. Multiple SGCs throughout the day provide a timeline of data changes to identify the attack window
3. Original corrupted production volumes are retained (not immediately deleted) for forensic analysis of the attack vector
4. Clean-room validation results provide data about which SGC are clean versus corrupted, helping identify the attack timeline
5. FCM4 threat detection logs provide information about when and where suspicious storage activity was detected.
Q-s48: Where can I learn more about storage in IBM Power Cyber Vault?
A: For more information about storage in IBM Power Cyber Vault, contact IBM Technology Expert Labs to schedule a Power Cyber Vault Workshop. The workshop includes detailed assessment of your storage infrastructure, capacity planning, architecture design, and recommendations for implementing Cyber Vault with IBM FlashSystem or DS8000 storage. You can also refer to the following resources:
- IBM Power Cyber Vault Overview - Video
- IBM FlashSystem Product Information
- IBM DS8000 Product Information
- IBM Copy Services Manager Information
- IBM Storage Insights Information
Q-s49: Why do we not use IBM CDM and Sentinel to perform scanning?
A: IBM Copy Data Manager (CDM) does not currently have the flexibility to be used for the workflows needed. If, and when the required APIs are available, it is planned to integrate with both CSM and CDM to provide an option.
Q-s50: Which storage replication solutions do IBM Power Cyber Vault support?
A: For application-consistent SGCs, IBM PCV needs to be presented the source volume to quiesce the application. For crash-consistent SGCs, a target from any replication method supported on FlashSystem or DS8000 can be used.
Q-s51: Are all storage volumes protected and validated?
A: Yes, the clean room validation is against an exact copy of the production VM, including root and data volumes.
A: 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.
Q-p2: What is the PowerSC Graphical User Interface (GUI) Server?
A: The PowerSC GUI Server is the centralized server that provides monitoring and configuration of security events deployed on PowerSC managed endpoints, called PowerSC Graphical User Interface Agents.
Q-p3: What is the PowerSC Graphical User Interface (GUI) Agent?
A: The PowerSC GUI Agent is the endpoint component that is managed by the PowerSC GUI Server. Various security measures are configured on the PowerSC GUI Agent. When events occur related to these security measures, the event is report to the PowerSC GUI Server.
Q-p4: Where can I learn more about PowerSC?
A: The following link is the main document repository for PowerSC: PowerSC Documentation
Q-p5: Does IBM Power Cyber Vault provide a license for PowerSC?
A: No. PowerSC licensing must be acquired separately. PowerSC can be obtained in the AIX Enterprise Edition licensing bundle or it can be purchased stand-alone using the core-based subscription. Please contact your Power hardware seller for more details.
Q-p6: How is PowerSC used in IBM Power Cyber Vault?
A: PowerSC provides detection of security events that occur on PowerSC GUI Agents ( monitored endpoints) which are then reported to a PowerSC GUI Server. The PowerSC GUI Server then reports these events to the Cyber Vault Event Driven Automation (CVEDA) component. The CVEDA will respond to the event depending on how the Cyber Vault Response Policy (CVRP) is defined for a given endpoint. (For more on the CVEDA and CVRP see the Ansible tab: Q-a4,Q-a6)
Q-p7: How does PowerSC monitor an enterprise protected by IBM Power Cyber Vault?
A: The standard enterprise endpoint will be installed and configured with a PowerSC GUI Agent. PowerSC provides support for configuring various security measures on the endpoint. All PowerSC GUI Agents report security events related to the configured security measures to one centralized PowerSC GUI server. The PowerSC GUI Server forwards security events to the CVEDA. Non-PowerSC tools, like ZTEA, are able to also communicate security events to the PowerSC GUI Server when using the PowerSC Custom Event feature.
Q-p8: How do FCM4 ransomware alerts work with PowerSC?
A: PowerSC has a unique process for processing FCM4 alerts. (For more information on the FCM4 detection process see the Storage tab: Q18, Q19, Q25, Q27)
Q-p9: Can non-PowerSC security tools be integrated in IBM Power Cyber Vault using PowerSC?
A: Yes. Non-PowerSC tools to be integrated in Cyber Valt if PowerSC Custom Event REST API Programming for the non-PowerSC events has been implemented and CVRP support for the non-PowerSC events has been implemented. For more information about integrating non-PowerSC security tools using the PowerSC Custom Event Feature, contact your IBM Expert Labs Cyber Vault representative.
Q-p10: Can non-PowerSC security tools be integrated in IBM Power Cyber Vault without PowerSC?
A: Yes. (See Ansible tab: Q10)
Q-p11: How do I configure which PowerSC security events are sent to the CVEDA?
A: For each PowerSC GUI Agent, The PowerSC GUI Server allows you to specify the exact subset of security events to be reported to the CVEDA using the PowerSC "syslog" alert response option. When a given endpoint and security event type has been configured with a "syslog" alert response, the PowerSC GUI Server will forward the security event to the CVEDA when the event actually occurs on the endpoint.
Q-p12: Can PowerSC be configured to support a Security Information and Event Management (SIEM) Server and the CVEDA at the same time?
A: Yes. The same set of events that have been configured to use the PowerSC "ssh" alert response can be forwarded to your SIEM Server and the CVEDA.
Q-z1: What does ZTEA stand for?
A: IBM Zero Trust Execution for AIX.
Q-z2: What Is ZTEA?
A: ZTEA is a real time malware defense for AIX that uses a Zero Trust approach. ZTEA is designed to detect, an optionally prevent, the execution of all types of software-based malware (including ransomware, zero-day malware, hacking tools, next-generation malware, exploitation software, polymorphic malware, viruses, root kits, worms, and trojans).
Q-z3: Where can I learn more about ZTEA?
A: See the ZTEA website for full information about ZTEA: ZTEA Website
Q-z4: Is there a customer reference or review of ZTEA?
A: Yes. John McLaughlin, the AIX manager for the State of Ohio, has posted a very positive reference and review of ZTEA on Linkedin. John manages a very complex AIX environment and has successfully deployed ZTEA to several hundred AIX logical partitions. The reference can be viewed at: ZTEA Customer Reference
Q-z5: If an organization is considering adopting IBM Power Cyber Vault, when is ZTEA deployed?
A: ZTEA can be deployed completely independent of IBM Power Cyber Vault. Therefore, ZTEA can be deployed before, during, or after the deployment of IBM Power Cyber Vault.
Q-z6: How does an organization get started with deploying ZTEA?
A: Adopting ZTEA requires an initial consulting phase (Phase 1) followed by a subscription phase (Phase 2). Phase 1 consists of a ZTEA consultant providing consultative assistance with ZTEA deployment across the number of AIX LPARs requested. Phase 1 duration can span either 3 months, 6 months or 1 year. Phase 2 consists of the ZTEA Subscription. The ZTEA Subscription phase provides on-going licensed access to ZTEA, ZTEA updates, and ZTEA technical support. The price for the ZTEA Subscription depends on the number of physical cores used with AIX and ZTEA in the client enterprise. For additional information about getting started with ZTEA see: Getting Started with ZTEA
Q-z7: Is ZTEA available for Linux?
A: No. ZTEA is only available for AIX.
Q-z8: Does ZTEA come with PowerSC?
A: No. ZTEA is a completely separate licensed IBM product. Licensing is obtained from IBM Expert Labs.
Q-z9: What is the difference between ZTEA and other traditional malware defense security measures?
A: ZTEA is designed to provide comprehensive malware defense for AIX using a Zero Trust approach. ZTEA is a combination of three different, but complimentary, security measures: allowlisting, malware signatures, and hashing. ZTEA also achieves a malware defense synergy with allowlisting and malware signatures. See the following section on the ZTEA website for full details about this synergy: Malware Defense Synergy
Q-z10: What is allowlisting, and how is it used by ZTEA?
A: Allowlisting is one of the three distinct security measures used by ZTEA. Allowlisting is a security measure for detecting or preventing execution of unauthorized executables. In order for an executable to be authorized, the executable must be registered to an “allow list”. Allowlisting is accomplished on AIX by using AIX Trusted Execution, a component of the AIX base operating system. AIX Trusted Execution uses the AIX kernel to instantly detect when the security attribute of a registered executable has been altered. AIX Trusted Execution also uses the AIX kernel to instantly detect executables that are not registered to the allow list. See the following section of AIX 7.3 documentation for more information about AIX Trusted Execution: AIX 7.3 Trusted Execution Documentation
Q-z11: What are malware signatures, and how are they used by ZTEA?
A: Malware Signatures are one of the three distinct security measures used by ZTEA. Signature-based malware scanning compares files against a database of known malware. It is very fast and accurate for known threats. This is accomplished on AIX by using ClamAV. ClamAV is an open-source anti-virus engine. ClamAV scans for over 8.7 million trojans, viruses, malware, ransomware, and other malicious software. ClamAV's database includes over 20,000 ransomware signatures.
Q-z12: Does ZTEA use allowlisting and signature-based malware scanning in tandem?
A: Yes. ZTEA will take the new executables detected by AIX Trusted Execution and have them verified by ClamAV. When a registered executable is executed that doesn't conform to its registered security attributes, AIX Trusted Execution will log this security event. ZTEA will take this security event and will invoke ClamAV to verify that the corresponding executable has not been replaced with malware.
Q-z13: What is hashing, and how is it used by ZTEA?
A:Hashing is one of the three distinct security measures used by ZTEA. ZTEA Hash Cross-referencing is an optional advanced security measure that can be used with ZTEA. This measure consists of collecting SHA-256 hashes of executables from known "trusted" or "secure" systems and then creating flat file databases of those hashes that can be used on other system to verify the executables detected by ZTEA functionality. When the hash of an executable can not be mapped to a "trusted" or "secure" hash, ZTEA reports the executable as "unknown". "Unknown" hashes should be considered suspicious, and additional effort should be taken to definitively determine if the hash indeed corresponds to malware.
Q-z14: Since ZTEA is not a part of PowerSC, how does it communicate with PowerSC?
A: ZTEA is able to communicate with the PowerSC GUI Server using PowerSC's Custom Event feature. The PowerSC Custom Event feature allows non-PowerSC tools to have a degree of semi-integration with PowerSC.
Q-z15: How is ZTEA integrated into PowerSC?
A: By implementing support for the PowerSC Custom Event feature, ZTEA has achieved a degree of semi-integration with PowerSC. The PowerSC Custom Event feature allows non-PowerSC tools to report events to the PowerSC GUI Server. When a tool implements PowerSC Custom Event support, it allows the tool to report events to the PowerSC GUI Server using PowerSC's Security Alert capabilities. PowerSC's security alerting allows up to three responses for an alert: email, syslog, or shell script. See the "Creating custom events" topic in PowerSC documentation for more information about PowerSC's Custom Event feature: IBM PowerSC Documentation
Q-z16: What does Cyber Vault do if malware is detected by ZTEA?
A: That depends on how your CVRP is defined. Typically you would want to respond with an immediate SGC for an endpoint that generates a malware detection event, but it's possible to not respond to a malware event, although not generally recommended.
Q-z17: What ZTEA security events are currently supported by the Cyber Vault Response Policy?
A: See the ZTEA section on the CVRP Event Support page for full details: CRVP Event Support
Q-z18: Does ZTEA require additional CPU resources
A: No. Typically, no additional resources need to be added to your existing LPARs
Q-z19: Does ClamAV require additional resources?
A: Yes. At least 8GB memory is needed per LPAR. Additional CPU resources may be needed if you run full system scans from PowerSC.
Q-z20: Does AIX Trusted Execution require additional resources?
A: No. Typically, no additional resources need to be added to your existing LPARs
Q-z21: Does ZTEA provide a "learning" mode?
A: Yes. ZTEA provides extensive functionality for automating its deployment on AIX.
Q-z22: What benefits are provided when using ZTEA with PowerSC?
A: See the following section on the ZTEA website for full details: How ZTEA Enhances AIX Malware Defense, When Paired with PowerSC
Q: What are all the acronyms related to IBM Power Cyber Vault?
A: Please see the diagram below:
| Acronym | Full Term | Description |
| AAP | Ansible Automation Platform | Red Hat's enterprise automation solution |
| CSM | Copy services Manager | IBM storage management software for FlashCopy operations |
| CVRP | Cyber Vault Response Policy | Defines automated response actions for security events |
| CVEDA | Cyber Vault Event-Driven Automation | Event processing engine within AAP for Cyber Vault |
| EDA | Event-Driven Automation | AAP capability for automated event-triggered workflows |
| FCM4 | FlashCore Module 4 | FlashCore Module (FCM4) is IBM's fourth-generation custom-designed solid-state drive technology that includes built-in real-time threat detection capabilities. |
| HMC | Hardware Management Console | IBM Power Systems management interface |
| LPAR | Logical Partition | Virtual server instance on IBM Power Systems |
| RBAC | Role-Based Access Control | Security model for delegating administrative access |
| SGC | Safeguarded Copy | Immutable storage snapshot for cyber recovery |
| SIEM | Security Information and Event Management | Centralized security monitoring system |
| ZTEA | IBM Zero Trust Execution For AIX | ZTEA is an IBM product, developed by IBM Expert Labs, that provides malware defense For AIX using a Zero Trust approach. |
Was this topic helpful?
Document Information
Modified date:
26 March 2026
UID
ibm17250204