8.1 The role of security policy

Any computer environment has certain security characteristics, which can be accidental or intentional. For example, to make a computer totally secure, you might turn it off and place it in a locked closet. Arguably, such a computer is physically secure and under little threat of network attacks. It is not likely to be compromised or to affect other machines. However, it also accomplishes little of value to the company. If the computer is turned on, things get more interesting. And if it is attached to the Internet and running an e-business, then things get really interesting.

The mainframe is usually seen as having good security. However, as with any computer, the things required for good security on the mainframe do not come together magically. There is a need for a security policy, instead of letting accidental circumstances dictate security. A security policy is normally used to document desired system behavior. The policy should also guide the implementation of servers so that they have the desirable security characteristics that address various business risks.

A security policy is a comprehensive set of requirements that addresses how users are identified and authenticated, the roles and responsibilities of administrators, the capabilities of administrators and users, password policy, network policy, sharing policy, secure communication, administration of systems, maintenance requirements. Also included are resources and how they are defined and protected, hardening procedures and settings for each of the operating systems, auditing, logging, intrusion detection systems, and firewalls.

In the case of the orphan computer in the closet, the implicit context states that it is to do no work and have no users. Once the computer is turned on, a security policy is needed. The system administrator must determine if a human can manage this policy (typical in the home computer case), or if it must be documented as a procedure to be followed (done by many medium risk businesses), or if tools (like a policy manager) are required to enforce the policy.

Regardless of what kind of environment you are in, you probably already have a security policy in place. When considering a Linux-on-the-mainframe project, you will want to review your policy. Depending on the business value you are looking for from your project, you can follow different strategies. Two examples of objectives for Linux on the mainframe are:

  • Business value from consolidation: When Linux images are consolidated on the mainframe, you will probably also have z/VM to manage those images. Then z/VM must be considered in your policy as well. If, in the extreme case, your only goal is to consolidate as economically as possible, the isolation of images given by the hardware and z/VM may be all the additional security you need.

  • Business value from the speed-to-market of a business application: When applications running on Linux images interact with applications running on z/OS, the Linux applications should be close to the z/OS back-end, and connected to the z/OS images. In this case, you might need to review the policies that apply for your current environment and how they should be enforced on Linux on the mainframe. The implementation might be different for Linux from what it is for z/OS. For instance, by carefully segmenting the work, you might be able to isolate any new risks.

When evaluating the security policy for a Linux-on-the-mainframe project, you will want to know what risks are involved. We will look at risk assessment in the next section.



Linux on the Mainframe
Linux on the Mainframe
ISBN: 0131014153
EAN: 2147483647
Year: 2005
Pages: 199

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net