8.2 Risk assessment

Security is one of the first considerations for any server environment, whether it is a new system or an existing system that is used for new business opportunities.

All security is about managing risk. We have chosen a risk analysis approach as a framework for security. Using ISPCompany and StoreCompany as concrete examples, we first introduce some general aspects of security. Then we look at more details pertaining to the areas we introduce here, in particular, how they relate to Linux on the mainframe (see Figure 8-1).

Figure 8-1. Security space: what security covers

Linux is going to be tightly connected to many aspects of your e-business. Connecting the computer system to the Internet (that is, being connected to an external network) dramatically increases the risk of damage from intrusion.

Security is a trade-off between ease of use of the computing resources, business requirements for protection, and expense. There is no magic application or methodology that ensures the security of a system. Like all real-world technical designs, it is a practice of setting and meeting requirements and the consideration of limitations imposed by those requirements. Defending your Linux mainframe server is based on understanding these security requirements, best practices, and experience.

Naturally, the primary focus of a company is on its business and not on its systems. The goal of such systems is to support business and overall objectives. All business decisions, in IT or otherwise, are an exercise in the evaluation of the risk of inaction versus the cost of action to reduce risks (real or perceived).

8.2.1 What is risk assessment?

Risk can be defined as "being exposed to injury, pain, or loss." In every situation, your company is exposed to injury or loss. In the business context, there can never be zero exposure. The question is how to minimize that exposure and what level of exposure you can live with. Risk assessment, then, is the art of assessing what level of risk your company can accept.

Areas of risk assessment that pertain to Linux on the mainframe include:

• Hardware: Ensuring physical security of the machine itself and its console

• Network: Establishing secure communications, using encryption, protecting networks from being tapped, and from denial-of-service attacks

• Technology: Using virtualization technology

• Information: Protecting intellectual property (such as specialty applications) and protecting your data, which might be your most valuable asset

• Human: Minimizing the threat of damage by malicious individuals

One way to approach security and make sure that all areas of importance are covered is by performing an extensive risk analysis. This chapter concentrates on problem areas that need to be considered in a Linux-on-the-mainframe solution.

Figure 8-2 shows a typical Web-serving setup, where the machines are separate and discrete. Some of the typical attacks on this kind of setup are illustrated.

Figure 8-2. Risk areas of typical Web-serving setup

Going back to the examples of business value from Linux on the mainframe, what are examples of risks in those scenarios?

If you are doing simple server consolidation, the images are no longer on individual hardware machines. What is the risk from shared hardware? ISPCompany might be wondering how to guarantee that the servers that used to be in separate cages cannot touch each other's data now that they are on one machine. We discuss this in 8.2.3, "Partitioning" and 8.2.4, "Virtual security."

If you are integrating Linux into the existing mainframe environment to work closely with current business applications, one of the Linux images could become compromised. What could an intruder do in a Linux image? We discuss this in 8.4, "Opening the doors."

A Linux-on-the-mainframe environment usually benefits from virtual networks. What are the risks of virtual networking? We discuss this in 8.4.3, "Secure and encrypted communication."

Let us now take a closer look at the risk areas, and see what our example companies have done to reduce risk.

8.2.2 Hardware security

The first security stage is physical access to the floor where the computers are housed. Assuming that ISPCompany, as the typical data center, has tens of servers in one room, the normal way to protect these is to tightly control access to that room. Only the trusted people who work with the servers are allowed there. Often, all the consoles are logged on to save time. As a result, if someone does break in, he or she could tamper with the servers.

Consolidating many servers on the mainframe simplifies the physical security challenge. There are fewer reasons for anybody needing actual access to the physical machine. The system administrator can do most work with the individual servers running under z/VM from the control room.

The mainframe system console

For a direct attack on a system, the (hardware or operating) system console may be the goal of intruders. The mainframe, in contrast to other systems, has a separate hardware system console. (The zSeries operating systems each have their own system consoles.) The physical mainframe system console is shipped with the machine in the form of two IBM laptop computers, one serving as a hot standby backup. They are called Support Elements (SEs). The SE communicates with the internal sub-systems in the machine. For example, it handles initial program loads (IPLs), I/O configuration, LPAR configuration, and microcode updates.

A Support Element is normally not used directly. Instead, commands are sent through the Hardware Management Console (HMC) to the SE, as illustrated in Figure 8-3.

Figure 8-3. The HMC, the SEs, and a mainframe. Commands for operating, monitoring, and maintaining the mainframe are sent through the HMC to the SE, which then issues commands to the central processor complex.

The HMC serves as a single point of control to operate the machines defined to it remotely. The HMC must be connected to the SEs through a LAN. To be physically secure, the LAN that connects the HMC to the SE should be contained within the raised floor and control room. Through the LAN, you can also operate the systems through a Web interface to the HMC. The HMC is often placed in the control room in case staff need to take some hardware-related actions. (Refer to IBM eServer zSeries 900 System Overview, SA22-1071, for rules on setting up the HMC.)

Apart from physical isolation in an access-controlled room, the SE and HMC are protected by role-based user IDs and passwords. The HMC has a role-based model for access that provides a second layer of security in addition to logon authentication. Role-based means that there are user IDs for certain roles. Even if you have a user ID and a password, you cannot do everything, but only what the role allows.

You can enable remote support for the HMC. This is not automatically enabled.

ISPCompany example

ISPCompany solves the physical access problem by using the conventional method for the outsourcing business. It puts customers' machines in cages, so that any customer has access only to his or her cage. Customer personnel wanting to work in their cage must sign in at the front desk, have badge access to the part of the floor where their cage is, and use a key to open their own cage.

With ISPCompany's mainframes, the mainframes' consoles are connected through a private LAN to the control room, where an HMC acts as a single point of control for those mainframes.

With applications or servers consolidated on the mainframe under Linux, the access problem is now one of logical access rather than physical access. There is little need to touch the actual mainframe. The exception is one or two highly trusted experts who, for example, need to plug in the fiber optic cables to connect new adapters on the server to the fiber network hub. These experts are typically ISPCompany employees. Other situations that call for access to the mainframe are hardware modifications, such as installation of cryptographic cards.

Moving a physical server farm with servers or applications to run on Linux images under z/VM, decreases the risk of physical attack. Instead, security under z/VM, which we examine in detail in 8.2.4, "Virtual security," becomes interesting. You also then need to manage the Linux images "remotely." This can be done with the help of, for example, a virtual private network (VPN) and secure shell (SSH) both of which we discuss later in this chapter.

8.2.3 Partitioning

Logical partitioning (LPAR) provides a flexible alternative for dividing a machine's CPU resources and also guarantees the isolation of the software images running in the individual partitions using the same concepts explained above. The isolation of the partitions is proven by an independent authority. For the most up-to-date information on the technology that provides logical partitioning, see http://www.ibm.com/servers/eserver/zseries/security/certification.html.

8.2.4 Virtual security

A common question asked by technologists interested in running multiple Linux images on z/VM for the first time is, "How good is z/VM's system integrity and security?" The short answer is "very good." The much longer answer offers some additional insight into the technology found in the z/VM product.

Because the z/VM Control Program (CP) and the virtual machine configurations are under the control of the z/VM system administrator, the actual level of system integrity that a company achieves depends on how the z/VM environment is set up and maintained. z/VM is specifically designed to maintain the isolation of one virtual machine from other virtual machines at all times.

The IBM ESA/390 architecture and z/Architecture are at the core of the system's ability to maintain integrity. One crucial aspect of this is the ability to keep each virtual machine isolated from every other virtual machine. This isolation even extends to the CP, because it is logically separate from all virtual machines in the system.

How z/VM keeps it all separate

A special component of the mainframe virtualization technology permits a virtual machine instruction stream to be run on the processor using a single instruction, start interpretive execution (SIE).

When the CP dispatches a virtual machine (that is, executes SIE), details about the virtual machine are provided to the hardware. The SIE instruction runs the virtual machine until the virtual machine receives an interrupt, or wants to perform an operation that either the hardware cannot virtualize or for which the CP must regain control. At that point, SIE performs an exit on behalf of the virtual machine and returns control to the CP, which simulates the instruction or performs the I/O (for example). Once this is done, control is returned to the virtual machine. In this way, the full capabilities and speed of the CPU are available to the virtual machine, and only those instructions that require assistance from or validation by the CP are intercepted.

This mechanism also enables the CP to limit the scope of many kinds of hardware or software failures. When the error can be isolated to a particular virtual machine, only that virtual machine fails. It can be re-initialized (rebooted) without affecting work running in other virtual machines. The CP is designed so that failures that occur in virtual machines do not affect the CP or other virtual machines.

Isolation through address translation

While most platforms today offer virtual memory, zSeries allows an operating system to create separate virtual address spaces. Address spaces enable memory isolation and management. For example, z/VM running natively on a zSeries machine creates a separate address space for each guest. Each address space has an associated set of region, segment, and page tables that contain precise information on the real memory locations being used for the guest. These tables are used by the address-translation hardware to convert virtual memory addresses to real memory addresses. Because these tables are maintained by the operating system and are not accessible by the guests themselves, it is not possible for a guest to read from or write to memory that is used by the operating system itself or another guest.

zSeries takes this capability a step further by supporting two levels of address translation. An operating system running in a virtual machine under z/VM constructs its address-translation tables as usual to isolate and contain the memory for its users. The entire memory of this virtual machine, although viewed by the guest operating system as real memory, is in fact virtual storage as well, defined by another set of translation tables managed by the z/VM CP. Even if an application running on a guest operating system were able to compromise the integrity of the guest, the damage would be limited to that one virtual machine, because of the separate layer of protection provided by zSeries hardware and z/VM.

A virtual machine cannot access an address space owned by another virtual machine unless the address space owner explicitly allows the virtual machine to do so. This capability is controlled through the z/VM directory entry for each guest.