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:
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.