Segmentation in mainframe z/OS and LPM

Brief introduction to mainframe 

Mainframe computers play a central role in the daily operations of the world’s largest corporations. It dominates the landscape of large-scale business computing in banking, finance, health care, insurance, public utilities, government, and a multitude of other public and private enterprises.  The subject of this article will be how to improve its level of cyber security in order to best meet the requirements of the LPM.

Factors contributing to mainframe use 

The reasons for mainframe use are many but most of them lay beyond one of the following categories. 

  • RAS (Reliability, availability, and serviceability): Mainframe design places a high priority on the system always remaining in service. The system has error prevention and detection features, it can recover from a failed component without impacting the rest of the running system and determine why a failure occurred. 
  • Security: The mainframe provides secure system for processing large numbers of heterogenous applications that can access critical data and offers an unmatched protection for workload isolation, storage protection, and secured communications. 
  • Scalability: Mainframe can run multiple copies of the operating system software as a single entity. 
  • Continuing compatibility: Mainframe hosts old applications that evolved or not over the years and more recent applications development. The mainframe provides absolute compatibility across decades of changes and enhancement. When an incompatibility is unavoidable, the designers typically warn users at least a year in advance that software changes might be needed. 
  • Evolving architecture: Mainframe has been the leading technology in data and transaction serving for over four decades. Strong combination of past mainframe characteristics and next functionalities designed around the RAS are provided by each new generation. 
  • Extensibility: Mainframe component and infrastructure reuse is characteristic of its design (a share-everything architecture). 
  • Lower total cost of ownership (TCO). 
  • Environmental friendliness: Fewer physical servers running at a near constant energy level can host multiple virtual software servers. This setup allows a company to optimize the utilization of hardware and consolidate physical server infrastructure by hosting servers on a small number of powerful servers. 

 

Hardware Systems and high availability 

 To introduce mainframe hardware, we will take as example the Z16 generation mainframe systems offer: 

  • A high computing capacity (up to 200 processors) ensuring swift processing of tasks and handling of complex computations.  
  • A big capacity memory (up to 40 TB) enabling storage and retrieval of vast amounts of data rapidly. 
  • A memory cache optimizing performance.
  • Data compression capability facilitating efficient storage and transmission of data by reducing its size. 
  • Encryption functionalities to secure transactions providing robust security measures to safeguard sensitive information during transactions. 

Despite the continual changes, mainframe computers remain the most stable, secure, and compatible of all computing platforms. From the client-server model of computing in the early 90s to the significant increase of scalability and performance and capacity today the mainframe computers evolved to meet new challenges. 

Growth of the mainframe and its components

Z/16 generation mainframe are multiprocessor servers. Each processor has a small private area of memory that is unique to that processor called Prefix Storage Area (PSA) the processor can access other processor’s PSA through special programming, although this is normally done only for error recovery purposes. 

The mainframe disk drives are accessible through an associated Control Unit that has up to four fiber channel connections to one or more processors (through switch). 

 

System control and partitioning 

There are many ways to illustrate a mainframe internal structure. The figure bellow illustrates several internal functions of the mainframes. The internal controllers are microprocessors they are usually known as controllers to avoid confusion with mainframe processors. 

System control and partitioning

The mainframe can be partitioned into separated Logical PARtitions (LPARs) where system resources (memory, processors, and I/O devices) can be divided or shared among them under the control of LPAR hypervisor (type 1 hypervisor / native) which comes with the standard Processor Resource/ Systems Manager (PR/SM) feature on all mainframes. Each LPAR support independent operating system (OS) loaded by a separate initial program load (IPL) operation and has its own copy (most of the z/OS system libraries can be shared). 

Today’s machines can be configured with up to 60 LPAR, each one is considered as a distinct server with different OS environments. The system administrator can assign one or more system processors to the exclusive use of an LPAR through system control functions (firmware). 

Logical partition

 

Clustering 

Most z/OS installations nowadays use one or more of the following clustering technics: 

  • Basic Shared DASD (Direct Access Storage Devices): 

A basic shared DASD system is typically used where the operations staff controls which jobs go to which system and ensures that there is no conflict, such as both systems trying to update the same data at the same time. Despite this limitation, a basic shared DASD environment is useful for testing, recovery, and careful load balancing. 

Basic shared DASD 

  • CTC rings: 

CTC rings (Chanel To Chanel) function simulate an input/output device that can be used by one System Control Program (SCP) to communicate with another SCP. It provides the data path and synchronization for data transfer. 

z/OS can use the CTC ring to pass control information among all systems in the ring. This information can include usage and locking information for data sets on disks, job queue information, security controls and disk metadata controls. 

Basic sysplex 

The ring aspect is more obvious when more than two systems are involved. 

 

  • Parallel Sysplex: 

A sysplex system is one or more (up to 32 LPARS) z/OS images joined into a cooperative single unit using specialized hardware and software. It uses unique messaging services and can share special file structures contained within couple facility (CF) data sets. 

The Coupling facility (CF) is a logical partition that provides high speed caching, list processing and locking functions for sysplex. It contains one or more mainframe processors and a built-in operating system. 

A Parallel Sysplex is a symmetric sysplex using multisystem data-sharing technology. This is the mainframe’s clustering technology. It allows direct, concurrent read/write access to shared data from all processing servers in the configuration without impacting performance or data integrity. Each LPAR can concurrently cache shared data in the CF processor memory through hardware-assisted, cluster-wide serialization and coherency controls. 

This technic allows requests that are associated with a single workload to: 

  • Dynamically be balanced across systems with high performance. 
  • Improve availability. 
  • Provide a rolling maintenance for systems and applications. 
  • Offer a scalable workload. 
  • View multiple-system environments as a single logical route. 
  • Synchronizing the TOD clocks (Time Of Day clock service) on multiple servers which allows events occurring on different servers to be properly sequenced in time. 

Parallel Sysplex 

 

Mainframe security 

 

Mainframe Z system security systems (access control, authentication, access control lists…) are centralized inside one unique service called SAF (System authorization Facility). 

SAF doesn’t require any other security product, but it is generally completed with other security product called ESM (External Security Manager) like TSS and RACF. 

  • RACF: 

RACF (Resource Access Facility) is part of a global IBM offer named z/Os Security Server that includes an LDAP server, a z/Os Firewall technology, an Enterprise Identity Mapping component, RACF, … 

RACF provides Discretionary Access Control (DAC) and Role Based Access Control (RBAC) functionality. 

  • TSS: 

The mainframe z/OS SAF (System Authorization Facility) can be used to delegate all security tasks to Broadcom TSS (Top Secret Services).  

TSS is an External Security Manager (ESM) developed by Broadcom and it is responsible of managing identification, authentication, and access control for z/OS resources like datasets, TCP/IP stacks, and programs. Each process has an owner (UserID) who starts with no permissions by default, and a TSS security officer must grant access to resources. Application isolation is achieved by carefully managing the permissions given to different resources. Additionally, firewall filtering can be applied to both incoming and outgoing traffic of the mainframe. 

 

Mainframe compliance with the LPM 

What is the LPM? 

The LPM is a strategic French defence plan whose objective is to ensure the security of operators of vital importance, companies, or organizations, for whom the interruption of one or their vital mission(s) would have an impact on the security of the nation. 

It concerns the protection of Information Systems of Vital Importance (SIIV), on which these vitally important missions are based, and Points of Vital Importance (PIV), places hosting sensitive IS. 

It is relatively close to the NIS (Network and Information Security) directive about the security requirements to be applied to its SIIV but integrates new notions and obligations which make it more restrictive. 

 

Why is the mainframe subject to the LPM? 

Mainframe z/OS (MFRz) is in the heart of the banking activity due to several reasons: 

  • Its capability of managing big transaction and compute volumes. 
  • It offers a modularity inside a centralized system. 
  • Scalability and openness of the system. 
  • Interesting costs. 

How can we perform segmentation in the mainframe? 

To ensure isolation of assets inside the mainframe we can identify three possible scenarios (complete isolation, dedicated LPAR and network isolation).  

The following scenarios however does not provide microsegmentation between assets in the same VLAN or sharing the same TCP/IP stack. 

 

Complete isolation 

A dedicated mainframe instance is dedicated for the SIIV assets. All communications with external asset are filtered through the mainframe firewall. However, this solution has a high material cost with a big operational risk. SIIV asset should be all migrated to this new mainframe instance and the building of this new environment require human resources. 

Complete isolation example 

 

Dedicated LPAR 

In this isolation scenario an LPAR is dedicated for the SIIV assets. As discussed in the “System control and partitioning” chapter mainframe can be partitioned into separated logical partitions (LPARs) where system resources and each LPAR support independent operating system (OS). 

Isolating all the SIIVs in one LPAR is not feasible because each asset runs on a different OS (Linux, z/OS…). 

LPAR isolation examples 

 

 

A dedicated LPAR per SIIV OS can be set to remediate to that. This solution has however some weakness: 

  • The SIIV assets share the same physical server with non SIIV assets. 
  • Adding resources allocated to these new LPARs will induce an increase of the cost.  

 

Network isolation 

Assets can be logically partitioned through PR/SM (IBM processor resource / system manager). Using this feature mainframe urbanization can be designed to optimize the use of resources, by dedicating partitions by environment or by type of service. Each partition has its own TCP/IP stack and one or more OSA cards (network cards that can be shared between partitions).  

Mainframes can be connected to different networks, that are accessible through these various TCP/IP stacks. Multiple stacks can run on one mainframe instance allowing one z/OS partition to communicate to multiple networks at the same time and each stack is not necessarily active on each z/OS partition.  

Network isolation example 

  • Two assets sharing the same TCP/IP stack can directly communicate with each other without the mainframe firewall filtering (example: communication between “SIIV asset 1” and “SIIV asset 2”). 
  • Two assets hosted in different LPAR but sharing the same VLAN can directly communicate with each other without the mainframe firewall filtering (example: communication between “SIIV asset 1” and “SIIV asset 3”). 
  • Two assets hosted in different LPAR and different VLAN have their communication filtered by the mainframe firewall (example: communication between “SIIV asset 1” and “Other asset 4”). 
  • Any communication with assets outside of the mainframe is filtered by the mainframe firewall. 

 

This network isolation scenario allows isolation of SIIV from non-SIIV resources inside the mainframe, the optimization of the mainframe is preserved and there is a low operational risk as we don’t move the SIIV resources outside the mainframe. 

 

Summary of solutions 

 

Do the segmentation scenarios respond to the architecture security filtering criteria of the LPM? 

 

The Complete isolation scenario responds fully to the LPM Partitioning and filtering requirement as the mainframe will be dedicated to the SIIVs and the incoming and outcoming flows will be filtered by the mainframe firewall. However as stated above this solution has several disadvantages mostly related to the cost and operational risk of moving all the SIIVs to another physical machines.  

The Dedicated LPAR provides a logical isolation layer. The SIIVs are hosted in dedicated LPARs each one with its dedicated resources inside the mainframe. However this solution can lead to performance issues and high material cost. 

The network isolation scenario provides an extra layer of network isolation relying on TCP/IP stacks however non-SIIV application hosted in the same network as SIIV applications can still directly access it without filtering to remediate that the following conditions must be met: 

  • Dedicated SIIV zones must be set in the IS where group application will be hosted. 
  • Dedicated TCP/IP stacks must be set in the mainframe to which the SIIVs will be connected. 

In this scenario non-group critical resources communications with SIIVs will be forced to go through the firewall filtering. 

 

Administration of the mainframe 

 HMC 

IBM z systems hardware monitoring and control services are performed through a dedicated console (HMC: Hardware Management Console) located in operator area and a Support Element console (SE) located inside a CEC (central electronic complex – mainframe “box”) that can only be used by operators. The HMC is a physical computer located in an operator area and is dedicated to the management of the hardware and software of the mainframe. The HMC can’t be used for another purpose. IBM can perform support actions through distant connections RSF (Remote Support Facility) for reporting and patching hardware issues. Access to the OS and application layers can’t be performed through these consoles.  

  •  To ensure compliance with the LPM, the HMC access must be protected by a firewall and restricted to a Bastion. 

 

Administration applications 

IBM z systems embed several applications use to administrate the mainframe, such as TSO (Time Sharing Option), ISPF (Interface System Productivity Facility). These command-line interfaces allow users to run commands, submit batch jobs, manage rights and perform various administrative tasks. Access to those applications is managed through RACF (Resource Access Control Facility) which authenticate users and control the permissions based on assigned roles and access rights. 

To restrict the access to these administrative applications, the following measures must be deployed: 

  • Two network interfaces must be configured: one dedicated to mainframe administration, and one dedicated to business.  
  • RACF protection must be enabled on those interfaces to restrict the access based on the accounts. To do so, RACF should be configured to check the Terminal class4 and grant access based on its content: 
    • Administrators accounts can only access the administration interface 
    • Business users accounts can only access the business interface 

To ensure compliance with the LPM, the administration interface access must be protected by a firewall and restricted to a Bastion. 

 

 

 

 

Mainframe segmentation remains a critical component for organizations managing SIIVs. As we have explored, mainframe architecture provides a robust foundation for implementing effective segmentation strategies. 

The isolation solutions we have discussed each offers unique advantages and challenges. Complete isolation using dedicated mainframes is fully compliant with the LPM but at a higher cost, higher operational risk with reduced flexibility. LPAR isolation have a high operational cost and breaks the optimization of the MFRz. Network isolation using TSS or RACF to dedicate TCP/IP stacks offer a more cost-effective, flexible solution with less operational risks but this solution is partially compliant with the LPM as the mainframe is not physically dedicated to the SIIVs. In addition to that the mainframe provides the necessary tools to secure its administration interfaces and to segregate it from the production. 

Choosing between these solutions requires careful consideration of an organization specific needs, security requirements and resource constraint. It is crucial to remember that there is no one-size-fits-all solution. The optimal approach will vary depending on the nature of the SIIV and the organization overall IT infrastructure. 

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top