Cleaning House for the Next Generation: Security Minus Obscurity

by Reginald (Reg) Harbeck
April 1, 2006

In today’s security-conscious world of regulations, hackers and terrorists, many mainframes aren’t as secure as they should be.

Why is that? Obscure configurations—“loose ends,” so to speak—that result from incomplete, out-of-date or overly customized approaches to security. Once upon a time, these might have seemed to add greater security by their sheer obscurity, but today they’re just obstacles for a new generation of security professionals.

Loose ends are a big problem, particularly as the current generation of mainframe technologists retires and a new, smaller, less-experienced group takes their place. Leaving a mess of obscure loose ends is a sure-fire way to expose an environment to security gaps. Having solidified security in place allows for these individuals to prove their experience while posing minimal threat to an organization’s mainframe systems.

In order to understand how to correct this, let’s wrap up some of those loose ends by taking the following steps:

1. Finish installing and configuring security software

2. Ensure the security software is configured to meet the current business needs

3. Consolidate diverse application internal security into the external security system

4. Clean out obsolete user IDs and access—and keep them clean

5. Change utility passwords—and simplify future changes

6. Tighten controls on JCL libraries and started tasks.

Let’s explore each step in greater detail.

Finish installing and configuring security software: It’s easy to reach a point of “good enough,” but it’s time to move to “complete.”

When organizations first installed security software on their mainframes, they had to carefully implement it so users weren’t inadvertently locked out of critical business resources. Security was defined a piece at a time. Security software was dormant for those areas that hadn’t been explicitly defined to the security system. Organizations may have set the system to issue a warning when a security rule was violated, for example, but they didn’t turn it all the way on until they were sure it wouldn’t block user access to applications.

Ideally, the day would come when everything was secured, and the security software was configured to deny access by default to any ID that didn’t have explicit access to a resource.

However, for many organizations, that day never came. Instead, security is turned on for those resources they know about, but new resources (such as files) slip under the radar until someone arranges for their security.

That means production data is going unsecured. Organizations must finish the job and close this loophole.

Ensure the security software is configured to meet the current business needs: The book, Practical UNIX and Internet Security, by Simson Garfinkel and Gene Spafford (Second Edition, April 1996, ISBN: 1-56592-148-8), offers the following definition of computer security: “A computer is secure if you can depend on it and its software to behave as you expect.”