CIS 8.1 Safeguards Fulfilled on AIX by Using PowerSC, ZTEA, and PCV - Details

ZTEA provides simplified, automated, and advanced configuration of AIX Trusted Execution.  AIX Trusted Execution is a component of the AIX base operating system. AIX Trusted Execution provides the allowlisting of authorized software, as recommended by this safeguard.

AIX Trusted Execution provides kernel-based allowlisting, which is a very powerful countermeasure to not just ransomware, but also to all types of malware. In addition to allowlisting, AIX Trusted Execution provides a database containing digital signatures of AIX operating system files. Trusted Execution allows you to use these digital signatures to cryptographically verify that the AIX executables installed on your system are identical to the ones published by IBM and thus ensure they haven’t been altered by a hacker. 

Two approaches are available for implementing allowlisting using the AIX Trusted Execution tool. The easier option is to simply detect executables that aren’t allowlisted. An alternative approach is to prevent the execution of files that aren’t allowlisted. The latter reduces security risk to a greater degree but requires more effort to correctly implement. ZTEA currently only supports the detection mode of AIX Trusted Execution. Support for prevention mode is in the ZTEA roadmap, but it is not expected to release till 2027 or after.

When ZTEA is initially deployed, it will go through an initial learning period. This learning period will allow ZTEA to automatically register executables not already registered to the AIX Trusted Execution database. Before ZTEA adds a new executable to the AIX Trusted Execution database, ZTEA will use ClamAV to verify that the new executable doesn’t correspond to a known malware signature.

Learn More at: 
ZTEA Website

ZTEA provides simplified, automated, and advanced configuration of AIX Trusted Execution. AIX Trusted Execution is part of the AIX base operating system. AIX Trusted Execution provides the allowlisting of authorized libraries, as recommended by this safeguard. 

See Safeguard 2.5 above for more information about how ZTEA uses AIX Trusted Execution for allowlisting.

ZTEA provides simplified, automated, and advanced configuration of AIX Trusted Execution. AIX Trusted Execution is part of the AIX base operating system. AIX Trusted Execution provides the allowlisting of authorized scripts, as recommended by this safeguard. 

See Safeguard 2.5 above for more information about how ZTEA uses AIX Trusted Execution for allowlisting.

PowerSC Real Time Compliance is a component of PowerSC that allows you to monitor for access changes to files and directories on AIX. This component provides the configuration of data access control lists, as recommended by this safeguard.

Approximately 300 files are registered by default. The PowerSC administrator can add additional files and directories for access monitoring. When any user changes the access to one of the monitored files or directories, PowerSC Real Time Compliance will immediately generate an access change alert.

PowerSC Real Time Compliance uses event-based detection implemented at the kernel level. This provides an extremely CPU-efficient solution for detecting unauthorized access changes to files and directories.

Learn More at: 
PowerSC Documentation - Real Time Compliance

ZTEA provides simplified, automated, and advanced configuration of AIX Trusted Execution. ZTEA provides the configuration of data access control lists, as recommended by this safeguard.

AIX Trusted Execution is part of the AIX base operating system. AIX Trusted Execution implements data access control by specifying the expected ownership and file permissions for individual files and directories. Once a file or directory is registered in the AIX Trusted Execution database, the access can be verified on an on-demand basis.

If an existing registered file is altered, the subsequent execution of the file will result in AIX Trusted Execution detecting that the file doesn't conform to its registered definition.  AIX Trusted Execution will then generate a syslog alert.

The syslog alert is handled by ZTEA.  ZTEA will use ClamAV to verify that the new file doesn't correspond to any known malware signature. If the new file is not malware, ZTEA will automatically re-register the file to the AIX Trusted Execution database. This event will be reported to PowerSC as a 'checking error" by ZTEA.

ZTEA provides several capabilities for proactively defining access control lists using files and directories.

Learn More at: 
ZTEA Website

PowerSC Real Time Compliance is a component of PowerSC that allows you to monitor for modification and disposal of files on AIX. When any user changes or removes one of the monitored files, PowerSC Real Time Compliance will immediately generate an alert. This component provides logging of sensitive data access, as recommended by this safeguard.

Additional sensitive data access types, such as execution of a file or the reading of a file, could potentially be monitored with a combination of AIX Auditing that reports these auditable events to PowerSC using PowerSC's Custom Event Feature.

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, it will allow the tool to report its security events to the PowerSC GUI Server using PowerSC's security alerting configuration options and functions.

PowerSC provides the capability of running an on-demand integrity check of all files registered to the AIX Trusted Execution database.  This integrity check can detect unauthorized file modification, permission modification, and file deletion.

See Safeguard 3.3 above for more information about PowerSC Real Time Compliance

Learn More at:
PowerSC Documentation - Creating custom events

ZTEA provides simplified, automated, and advanced configuration of AIX Trusted Execution.  AIX Trusted Execution is a component of the AIX base operating system. AIX Trusted Execution provides the logging of sensitive data access, as recommended by this safeguard.

If an existing registered file is altered, the subsequent execution of the file will result in AIX Trusted Execution detecting that the file doesn't conform to its registered definition.  AIX Trusted Execution will then generate a syslog alert.

The syslog alert is handled by ZTEA.  ZTEA will use ClamAV to verify that the new file doesn't correspond to any known malware signature. If the new file is not malware, ZTEA will automatically re-register the file to the AIX Trusted Execution database. Using PowerSC's Custom Event Feature, this event will be reported to PowerSC as a 'checking error" by ZTEA.

ZTEA is able to detect when a new file is executed and then deleted, before being checked by ZTEA. The execution of the file is reported by AIX Trusted Execution to syslog. When ZTEA determines that the file is no longer on the system, ZTEA will report a "Deleted Executable" event to PowerSC using PowerSC's Custom Event Feature. A Deleted Executable event could have been the result of malware that was executed and then immediately deleted.

PowerSC Security and Compliance Automation is a component of PowerSC that implements security settings on AIX. This component provides a profile for implementing the CIS Benchmark for AIX, and one of the settings found in this profile implements the session locking, as recommended by this safeguard.

This component deploys sets of security settings using different compliance profiles. Each compliance profile corresponds to a different type of security standard. PowerSC provides profiles for standards such as: Payment Card Industry - Data Security Standard, Department of Defense STIG Compliance, HIPAA, etc. Each profile essentially consists of a set of compliance settings.

PowerSC provides extensive customization options:

1. Using the built-in compliance profiles, create any number of custom profiles that specify a different subset of settings
2. Modify general settings. For example, change the built-in password length requirement for all users from 14 characters to 16 characters.
3. Some settings provide advanced customization options. For example, require certain users to have a 14-character password length minimum requirement but other users to have a 16-character password length minimum requirement.

Learn More at: 
PowerSC Documentation - Security and Compliance Automation
CIS IBM AIX Benchmarks

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that insecure management protocols are not running on the AIX endpoint, as recommended by this safeguard. 

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that default accounts are properly managed, as recommended by this safeguard. 

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that unnecessary services are disabled or uninstalled, as recommended by this safeguard. 

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile implements a general policy for all users to have a minimum password length of 14 characters, as recommended by this safeguard. 

PowerSC Security and Compliance Automation also provides the ability to implement numerous customized password length options, if required. 

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that dormant accounts are disabled after 45 days of inactivity, as recommended by this safeguard. 

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

PowerSC Multi-Factor Authentication (MFA) is a component of PowerSC that provides extensive functionality for implementing MFA for remote network access on AIX, as recommended by this safeguard.

Technical Details:

• Supports numerous MFA types, including "phishing-resistant MFA"
• Supports Single Sign-On (SSO) by using OpenID Connect Protocol (OpenID)
• Numerous multi-factor policy configurations possible
• Centralized management provided by using the PowerSC MFA Server
• Automation supported by using REST API
• Numerous PMFA Client configuration options that provide flexibility and ease of use
• Supports high availability using PMFA server streaming replication
• Supports Payment Card Industry Data Security Standard (PCI DSS) MFA implementation requirements

Authentication Methods Supported:

• TOTP (for example, IBM TouchToken for iOS)
• Generic TOTP (for example, IBM Verify, Google Authenticator, Duo Mobile)
• SafeNet RADIUS
• RSA SecurID
• RSA SecurID RADIUS
• Gemalto SafeNet RADIUS
• Generic RADIUS
• YubiKey
• PIV/CAC or X.509 Certificate
• IBM Security Verify Access
• LDAP Simple Bind
• Local Password

Learn More at: 
PowerSC Documentation - Multi-Factor Authentication

The PowerSC Multi-Factor Authentication (MFA) component provides extensive functionality for implementing MFA for administrative access on AIX, as recommended by this safeguard. 

See Safeguard 6.4 above for more information about PowerSC Multi-Factor Authentication.

PowerSC Trusted Network Connect and Patch Management (TNC) is a component of PowerSC designed to provide continuous patch management for AIX and VIOS. TNC provides automated operating system patch management, as recommended by this safeguard. 

TNC provides update capabilities for interim fixes, service packs, technology levels, and open source packages.

Technical Details

• Point and click management provided by the PowerSC Graphical User Interface
• When a new interim fix or service pack is published by IBM, it is automatically downloaded to the patch repository
• TNC provides flexible and granular options for defining patch policies for environments with complex patch requirements
• Patch recommendations made upon the actual file sets installed on AIX or VIOS
• Extensive installation support, including open source packages in rpm & installp format
• Light-weight component architecture that provides excellent performance
• Automatic updating of patch repository that includes the updating of interim fixes with superseding versions
• Flexible command-line functions that facilitate automation
• TNC supports alt_disk updates for interim fixes, service packs, and technology levels

Learn More at: 
PowerSC Documentation - Trusted Network Connect and Patch Management
 

PowerSC Trusted Connect and Patch Management implements automated vulnerability scans for AIX endpoints on a quarterly, or more frequent, basis, as recommended by this safeguard. 

See Safeguard 7.4 above for more information about PowerSC Trusted Network Connect and Patch Management.

PowerSC Trusted Network Connect and Patch Management provides remediation of detected vulnerabilities in software on a monthly, or more frequent, basis, as recommended by this safeguard. 

See Safeguard 7.4 above for more information about PowerSC Trusted Network Connect and Patch Management.

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that several CIS-recommended AIX Benchmark logging enablement settings are implemented on the AIX endpoint. This component provides collection of audit logs, as recommended by this safeguard.

The PowerSC Graphical User Interface Server provides granular configuration for forwarding security events to a Security Information and Event Management (SIEM) server reported by PowerSC endpoints or non-PowerSC tools that implement the PowerSC Custom Event Feature.

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

Learn More at:
PowerSC Documentation - Creating custom events

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that several CIS-recommended AIX Benchmark settings for detailed audit logging are implemented on the AIX endpoint. This component provides collection of detailed audit logs, as recommended by this safeguard.

The PowerSC Graphical User Interface Server provides granular configuration for forwarding security events to a Security Information and Event Management (SIEM) server reported by PowerSC endpoints or non-PowerSC tools that implement the PowerSC Custom Event Feature.

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

Learn More at:
PowerSC Documentation - Creating custom events

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that CIS-recommended AIX Benchmark settings for sudo logging is implemented on the AIX endpoint in order to collect command-line audit logs. This component provides collection of command-line audit logs, as recommended by this safeguard.

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

The PowerSC Graphical User Interface Server provides granular configuration for forwarding security events to a Security Information and Event Management (SIEM) server reported by PowerSC endpoints or non-PowerSC tools that implement the PowerSC Custom Event Feature. This component provides centralization of audit logs, as recommended by this safeguard.

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

Learn More at:
PowerSC Documentation - Creating custom events

The PowerSC Security and Compliance Automation component provides a general-purpose profile for security hardening based on the CIS AIX Benchmark. This profile ensures that several CIS-recommended AIX Benchmark settings for detailed audit logging are implemented on the AIX endpoint. This component provides collection of service provider logs, as recommended by this safeguard.

The PowerSC Graphical User Interface Server provides granular configuration for forwarding security events to a Security Information and Event Management (SIEM) server reported by PowerSC endpoints or non-PowerSC tools that implement the PowerSC Custom Event Feature.

See Safeguard 4.3 above for more information about PowerSC Security and Compliance Automation.

Learn More at:
PowerSC Documentation - Creating custom events

PowerSC provides general malware defense for AIX using ClamAV. Once ClamAV is installed and configured on the PowerSC endpoint, PowerSC can schedule full or partial system scans to verify file systems do not contain malware. Working in conjunction with ZTEA and FCM4, PowerSC provides deployment and maintenance of anti-malware software, as recommended by this safeguard.

PowerSC also you to search for specific user-supplied malware hashes on PowerSC managed endpoints using the PowerSC Blocklisting feature. This feature supports MD5, SHA-1, and SHA-256 hashes

Learn More at:
PowerSC Documentation - Configuring anti-malware
PowerSC Documentation - Configuring the blocklist

IBM Zero Trust Execution for AIX® (ZTEA) is a real-time malware defense for AIX that uses a Zero Trust (ZT) 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). Working in conjunction with PowerSC and FCM4, ZTEA provides deployment and maintenance of anti-malware software, as recommended by this safeguard.

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

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

An executable is defined as any compiled file, script, library, or kernel extension loaded to memory and executed by the AIX operating system kernel.  This malware defense is implemented using ZTEA software in combination with several other security tools, including AIX Trusted Execution, ClamAV’s clamscan component, AIX syslog, and PowerSC.
 
Executables are validated in several ways:

1. Any executable that has not been authorized for execution will be detected by AIX Trusted Execution
2. Any executable that has had its content or file attributes altered in an unauthorized fashion will be detected by AIX Trusted Execution
3. Any executable that corresponds to a known malware signature will be detected by ClamAV
4. The hash of every executable is validated against a set of ZTEA Cross-referencing Hash Database (CRHD) files. Each hash is reported as either "Secure", "Trusted", or "Unknown".  A hash reported as “unknown” could be malware and would need additional verification to validate it is not malware.

Learn More at: 
ZTEA Website

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. Working in conjunction with PowerSC and ZTEA, FCM4 provides deployment and maintenance of anti-malware software, as recommended by this safeguard.

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.

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.

Learn More at:
PCV Website

PowerSC provides the option of setting up a local ClamAV database mirror that will allow PowerSC managed endpoints to retrieve the latest ClamAV database of malware signatures, as recommended by this safeguard.

See the PowerSC Detail section of Safeguard 10.1 above for more information about how PowerSC deploys and maintains anti-malware software. 

The PowerSC Graphical User Interface Server provides centralized management of ClamAV installed an AIX managed endpoints, as recommended by this safeguard.

The PowerSC GUI Server allows you to centrally define full system or partial system scans on AIX managed endpoints. See the PowerSC Detail section of Safeguard 10.1 above for more information about PowerSC anti-malware capabilities.

ZTEA facilitates centralized management of ZTEA's malware defense by reporting all malware related events to the PowerSC Graphical User Interface Server, as recommended by this safeguard. 

If a ZTEA scan detects malware on a PowerSC managed endpoint, ZTEA will communicate that security event using a REST API call that has implemented the PowerSC Custom Event Feature support.

Learn More at:
ZTEA Website
PowerSC Documentation - Creating custom events

FlashCore Module (FCM4) is IBM's fourth-generation custom-designed solid-state drive technology that includes built-in real-time threat detection (RTD) capabilities. FCM4 provides the behavior-based ant-malware software, as recommended by this safeguard.  

FCM4 uses behavioral analysis to detect threat activity patterns. See the PCV Detail section of Safeguard 10.1 above for more information about FCM4.

AUTOMATED SAFEGUARDED COPY CREATION

IBM Power Cyber Vault automates the creation of Safeguarded Copies (SGCs) — immutable, point-in-time snapshots on IBM FlashSystem or DS8000 storage — using Red Hat Ansible Automation Platform (AAP) as the orchestration layer. No manual administrator action is required to initiate, monitor, or verify backup creation. SGC creation completes in seconds using pointer-based snapshot technology with negligible production performance impact.

For workloads requiring strict write-order consistency (Oracle, DB2), Ansible coordinates a brief application quiesce before triggering the snapshot, producing a fully application-consistent and recoverable copy. Crash-consistent SGCs are also supported for applications that handle recovery natively.

TWO COMPLEMENTARY TRIGGER MECHANISMS

• SCHEDULED (PROACTIVE) PROTECTION
  • Configurable recurring schedules: every 4, 6, 8, or 24 hours, or custom intervals
  • Multiple schedules configurable per workload tier, aligned to Recovery Point Objective (RPO) and data sensitivity
  • Operates 24/7 independent of any security event; ensures baseline protection at all times
• EVENT-DRIVEN (REACTIVE) PROTECTION
  • Triggered within seconds of a security event detected by PowerSC, ZTEA, or IBM Storage Real-Time Threat Detection (RTD) hardware-based analysis
  • Creates an immediate out-of-cycle SGC — locking in a clean recovery point before the attack spreads further
  • Fully automated via Ansible Event-Driven Automation (EDA); no human trigger required

TIERED COVERAGE ALIGNED TO DATA SENSITIVITY

The Cyber Vault Response Policy (CVRP) allows organizations to define protection tiers by system criticality: mission-critical production systems receive the highest SGC frequency and immediate reactive protection on any security event; standard production and non-production systems follow appropriately configured schedules. This policy-driven approach directly satisfies the Safeguard 11.2's recommendation to calibrate backup frequency to data sensitivity.

HARDWARE-ENFORCED IMMUTABILITY

Once created, a Safeguarded Copy (SGC) is immutable at the storage hardware level: IBM FlashSystem and DS8000 enforce a retention lock that cannot be shortened or overridden by software or normal administrative action until the configured retention period expires. Early removal requires special privilege escalation available only in limited and controlled situations — it is not accessible through standard operational workflows. A ransomware actor who has fully compromised production systems and credentials cannot reach or corrupt SGCs through any standard access path.

Retention periods are configurable (typically 7–15 days or longer) and defined during the Cyber Vault design engagement.

ENCRYPTION OF RECOVERY DATA

Both IBM FlashSystem and IBM DS8000 support Data-at-Rest Encryption for all stored data, including SGC volumes. Encryption is implemented using local encryption key management or through integration with IBM Security Guardium Key Lifecycle Manager (SGKLM) for centralized enterprise key management. SGC data is encrypted on the storage medium, satisfying the encryption recommendation of Safeguard 11.3.

REACTIVE SGCS: MINIMIZING DATA LOSS DURING AN ACTIVE ATTACK

Traditional scheduled backups have an inherent vulnerability: the window between the last scheduled backup and the moment of attack detection represents potential data loss — a gap that can span hours. IBM Power Cyber Vault's Tier 3 reactive protection compresses this window fundamentally.

When threat detection fires — from IBM Storage Real-Time Threat Detection (RTD), hardware-based behavioral analysis embedded in FlashSystem and DS8000 storage modules, PowerSC OS-level security event monitoring, or IBM Zero Trust Execution for AIX (ZTEA) malware execution detection — Ansible's Event-Driven Automation responds within seconds by creating an immediate out-of-cycle SGC. This locks in a clean recovery point at the earliest detectable moment of the attack, before the threat has additional time to spread or encrypt further data. The recoverable data loss window shrinks from hours to seconds — a capability that traditional scheduled-only backup approaches cannot provide.

HOW IBM STORAGE REAL-TIME THREAT DETECTION (RTD) IDENTIFIES RANSOMWARE AT THE MODULE LEVEL
IBM Storage RTD is embedded inside FlashSystem and DS8000 storage modules, analyzing every block of data written in real time using dedicated on-chip processing — with no measurable impact on storage performance. Detection indicators include:

• Sudden collapse of compression ratios (encrypted data compresses poorly)
• Encrypted payload data patterns distinct from normal application data
• Abnormal sequential-rewrite behavior across large data ranges
• Block-access sequencing anomalies inconsistent with normal workload patterns

Because IBM Storage RTD uses behavioral analysis rather than malware signatures, it detects zero-day ransomware variants. When multiple indicators align, an alert is immediately forwarded to IBM Storage Insights and the PowerSC GUI Server, triggering automated response.

LOGICAL DATA SEPARATION

SGCs cannot be directly accessed or mounted. The only path to SGC data is through an explicitly orchestrated, logged, and Role-Based Access Control (RBAC)-controlled workflow: a recovery volume must first be provisioned from the SGC before any system can access the data. There is no direct network path from any production system — even a fully compromised one — to the SGC content. Recovery operations leave the original SGC completely unmodified.

CREDENTIAL AND ACCESS CONTROL

All credentials used to perform SGC operations are stored in Ansible Automation Platform (AAP)'s enterprise credential store, encrypted at rest with AES-256, never stored in automation scripts or version control, and automatically masked in execution logs. RBAC restricts which users and workflows can execute storage operations.

THE CLEAN ROOM: A DEDICATED AIR-GAPPED RECOVERY ENVIRONMENT

The clean room is a dedicated IBM Power server environment — physically and logically separate from all production systems, High Availability (HA) nodes, and Disaster Recovery (DR) replicas — air-gapped from the production network as a best practice. Clean room Logical Partitions (LPARs) exist solely for recovery and validation; they are activated only when an orchestrated workflow requires it, minimizing their attack surface during periods of non-use.

This directly addresses the structural gap in traditional HA/DR environments, where production, HA, DR, and backup systems share the same logical domain and network segment, allowing ransomware to propagate freely across all of them. The clean room breaks this shared domain model: there is no lateral movement path from a compromised production environment into the recovery environment.

MULTIPLE VERSIONED, IMMUTABLE RECOVERY INSTANCES

IBM Power Cyber Vault maintains a pool of multiple simultaneous, independent, and immutable Safeguarded Copies (SGCs), satisfying CIS 11.4's requirement for version-controlled backup destinations:

IBM DS8000: up to 1,024 SGCs per volume.
IBM FlashSystem: 15,863 to 64,999 total snapshots per system (model-dependent), shared across all volumes — enabling a large pool of versioned recovery instances across the protected environment.
This version-controlled pool enables forensic and surgical recovery: analysts can examine the SGC timeline, identify the point of first compromise, and recover from a precise clean point. When validation detects a corrupted SGC, administrators are alerted and can direct the system to test earlier SGCs to locate the newest clean copy — providing a meaningful forensic timeline of the attack.

NO DIRECT ACCESS PATH FROM PRODUCTION

SGCs cannot be directly mounted or accessed without an explicitly orchestrated, logged workflow that provisions a separate recovery volume first. There is no direct software or network path from any production system to the SGC data. This is a structural property of the architecture — not a policy control — and cannot be bypassed through elevated production credentials alone.

GEOGRAPHIC ISOLATION

IBM Power Cyber Vault supports a geographically separated clean room by replicating storage to an off-site location. This is achieved using IBM FlashSystem Policy-Based High Availability (PBHA) or Policy-Based Replication (PBR) for FlashSystem environments, or IBM DS8000 Peer-to-Peer Remote Copy (PPRC) for DS8000 environments. In all cases, the clean room at the secondary site operates under the same air-gapped architecture as a local clean room, with SGC workflows executed against the replicated storage. This satisfies Safeguard 11.4's reference to off-site systems as an implementation of isolated recovery data.

CONTINUOUS AUTOMATED VALIDATION — WELL ABOVE THE QUARTERLY MINIMUM

At Tier 2, IBM Power Cyber Vault performs scheduled proactive validation in the clean room on a configurable basis — daily, weekly, or a custom schedule — all exceeding Safeguard 11.5's quarterly minimum. Ansible orchestrates the entire workflow without manual intervention:

1. Ansible identifies the Safeguarded Copy (SGC) to validate based on the current schedule and protection history.
2. A recovery volume is provisioned from the SGC and mapped to a designated clean-room Logical Partition (LPAR) in the air-gapped environment.
3. Automated integrity checks are executed against the mounted copy.
4. Results are reported and recorded; the recovery volume is cleaned up. The original SGC remains unmodified.

Validation covers the complete production workload — root and data volumes — providing a full recovery test of the actual workload that would be restored in a real incident.

THREE-TIER INTEGRITY VERIFICATION

VALIDATION INTEGRITY CHECK TIERS

• Type 1 — IPL / OS Validation: The clean-room LPAR performs a full system boot from the recovered SGC, confirming the OS image is intact and bootable. A backup that cannot boot is not a viable recovery target; this check eliminates that risk before an incident.
• Type 2 — Data Structure Validation: Database schemas, application structures, and transaction logs are verified. For Oracle, tablespace and redo log consistency is confirmed. For DB2, buffer pool and log consistency is confirmed.
• Type 3 — Data Content Validation: Actual customer data is checked for integrity and consistency through business logic validation, data relationship checks, and custom application-specific tests configured by the organization.

Validation workflows can be customized with organization-specific scripts, industry compliance checks, and application-specific tests. IBM Zero Trust Execution for AIX (ZTEA) platform checks are included in the clean room validation sequence.

REACTIVE VALIDATION TRIGGERED BY SECURITY EVENTS (TIER 3)

At Tier 3, validation is also triggered automatically when a security event is detected by PowerSC, ZTEA, or IBM Storage Real-Time Threat Detection (RTD), which uses hardware-based behavioral analysis embedded in FlashSystem and DS8000 storage modules. The system creates an immediate SGC and initiates clean-room validation. When a corrupted copy is identified, administrators are alerted and staff review is initiated. If desired, the system can be configured to automatically test earlier SGCs to locate the newest clean copy; by default, this step awaits staff direction. The result: at the exact moment an attack is detected, the organization simultaneously captures a new clean recovery point and initiates verification of its integrity.

AUDIT EVIDENCE AND COMPLIANCE REPORTING

Ansible Automation Platform maintains a comprehensive job history for all validation workflows — timestamps, pass/fail results at each integrity check tier, SGC identity, clean room LPAR used, and full execution logs with user attribution. This audit trail provides documented evidence of recovery testing well beyond what manually executed quarterly tests can demonstrate. Integration with SIEM solutions is supported for centralized security monitoring.

The PowerSC Graphical User Interface (GUI) Server provides centralized management for numerous security measures on AIX. This component of PowerSC provides the centralized security event alerting, as recommended by this safeguard.

The PowerSC GUI Server typically interfaces with AIX endpoints using the PowerSC GUI Agent installed on the managed endpoint. Non-PowerSC tools can report security events to the PowerSC GUI Server by leveraging the PowerSC Custom Events Feature. ZTEA has implemented support for this feature, and is able to report ZTEA security events using the PowerSC Custom Event Feature. The PowerSC GUI Agent and the PowerSC Custom Event feature allow all managed endpoint to report security events to the centralized PowerSC GUI Server. The PowerSC GUI Server provides the ability to specify the exact subset of security events reported by managed endpoints that should be forwarded to a SIEM.

Learn More at:
PowerSC Documentation - PowerSC GUI Concepts
PowerSC Documentation - Creating custom events

PowerSC provides numerous security measures that provide host-based intrusion detection on PowerSC monitored AIX endpoints, as recommended by this safeguard:

1. PowerSC Real Time Compliance (RTC)
   By default, this component monitors the most critical subset of AIX operating system files involved with AIX security settings. When RTC was originally developed, AIX Security Development performed an analysis to determine the superset of AIX files involved with security configuration. The result of this analysis forms the baseline of files that are monitored by RTC. The rationale for monitoring these files is that if a bad actor is going to exploit an AIX system, the bad actor will likely require to alter one or more of these critical security files. This in turn will allow immediate detection of intrusion.
2. PowerSC Security and Compliance Automation
   This PowerSC component can deploy a profile that specifies a baseline of expected security settings on PowerSC monitored AIX endpoints. This component provides a profile for implementing the CIS Benchmark for AIX. When a profile is deployed on a monitored PowerSC AIX endpoint, periodic compliance checks can be run to verify compliance settings are deployed. If a compliance check returns a compliance failure event, this could indicate that  intrusion has occurred on the monitored endpoint.
3. PowerSC Host Intrusion
   PowerSC provides additional security measures used for host-based intrusion detection:
   1. PowerSC can detect if too many password attempts occur over a given number of minutes
   2. PowerSC can detect if port scans occur on a monitored endpoint
   3. PowerSC can detect if the syslog configuration has changed on a monitored endpoint
4. Additional PowerSC host-intrusion detection
   PowerSC monitors the configuration of the various security tools that are implemented on the PowerSC AIX monitored endpoints. Numerous security alerts are available for detecting configuration changes of these tools which could indicate intrusion by a bad actor.

Learn More at:
PowerSC Documentation - Monitoring endpoint security

PowerSC provides numerous security measures that provide host-based intrusion prevention on PowerSC monitored AIX endpoints, as recommended by this safeguard:

1. Security Event Endpoint Response with User-Defined Script
   When the PowerSC GUI Server receives a security event reported by a PowerSC-monitored endpoint, PowerSC allows you to define a response script that can be executed on the corresponding reporting endpoint. The definition of the response script can be unique to the particular security event and also the particular endpoint.
2.  User lockout after several failed password attempts
   If a user fails to login to a PowerSC-monitored endpoint after a certain number of attempts and over a certain duration, the user will be locked out from accessing the system. The number of attempts a duration can be configured on a per endpoint basis. An administrator would need to reenable access to the user.

ZTEA could provide host-based intrusion prevention by leveraging the preventative allowlisting capabilities of AIX Trusted Execution.

AIX Trusted Execution provides numerous capabilities for providing the host-based intrusion prevention, as recommended by this safeguard:

1. Locking the Trusted Signature Database (AIX Trusted Execution's database)
   An AIX Trusted Execution Runtime Policy can be activated to lock the TSD from modification. Even an administrator with root access would be unable to modify the TSD when this policy is activated. This policy can also be deactivated by root.
2. Requiring executables to be registered in the TSD
   An AIX Trusted Execution Runtime Policy can be activated that will require all executables to be registered in the TSD in order for the executable to be launched.
3. Requiring executables to conform to their TSD registration
   An AIX Trusted Execution Runtime Policy can be activated that will require all executables to align with their corresponding registration in the TSD. If an executable doesn't align to its TSD definition, it will be prevented from launching by the AIX kernel.
4. Locking TSD-registered executables
   An AIX Trusted Execution Runtime Policy can be activated that will not allow modification of executables defined in the TSD. Even an administrator with root access would not be able to modify a TSD-registered executable when this policy is activated.
5. Limiting the loading of executables to a specified subset of directories
   An AIX Trusted Execution Runtime Policy can be activated that will require all executables to reside in a particular set of directories in order for the executable to be launched.
6. Limiting the loading of libraries to a specified subset of directories
   An AIX Trusted Execution Runtime Policy can be activated that will require all libraries to reside in a particular set of directories in order for the executable to be launched.
7. Requiring a reboot for AIX Trusted Execution policy configuration changes
   All the policies described above can be dynamically activated and deactivated by an administrator with root access. To prevent alteration of these policies, an addition policy can be activated that will lock the policies into the AIX kernel. When this policy is activated, a reboot would be required to change the previously locked policies.

NOTE: ZTEA currently only supports AIX Trusted Execution configured in a detection-only mode.  Support for the prevention capabilities described above is in the ZTEA Roadmap for 2027 or after.

See Safeguards 2.5, 2.6, and 2.7 above for more information about how ZTEA uses AIX Trusted Execution for allowlisting.

Learn More at:
AIX Documentation - Trusted Execution

PowerSC supports port-level access control for managed endpoints by providing centralized management for the IP Security (IPSec) facility of AIX, as recommended by this safeguard.

On AIX, IPsec firewall rules are packet-filtering rules that work with AIX's built-in IP Security framework to control which network traffic is allowed, denied, encrypted, or authenticated.

An AIX IPsec rule can specify:

• Source and destination IP addresses
• Protocol (TCP, UDP, ICMP, etc.)
• Port numbers
• Actions to take
  • Permit
  • Deny
  • Apply IPsec protection (AH or ESP)
  • Bypass IPsec

Learn More at:
PowerSC Documentation - Configuring Intrusion Detection and Prevention (IDP) for AIX endpoints
AIX Documentation - Internet Protocol security