Cleaning House for the Next Generation: Security Minus Obscurity

by Reginald (Reg) Harbeck
April 1, 2006

** Read this article online at http://www.mainframezone.com/security/cleaning-house-for-the-next-generation-security-minus-obscurity


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

So, what do organizations expect of their mainframe systems? The same thing they expected when they were first made available: consistency, integrity, and privacy of their data and processing. And when their expectations were explicitly spelled out, mainframe security software was created to meet those requirements.

But “the way we’ve always done it” approach is no longer acceptable (and really never should have been). Business needs and regulations change. What was sufficiently secure when a system was written years ago may no longer meet today’s requirements. It’s akin to having so many passwords you keep them on a sticky note under the keyboard, thus creating a workaround that undermines the objective.

If current business needs are forcing people to work around the system rather than following it, it’s not appropriately configured. It’s time to re-examine your needs, identify the exposures that auditors and organizational executives would be concerned about, and ensure they’re explicitly dealt with.

Consolidate diverse application internal security into the external security system: When properly done, external security (i.e., allowing a software product to handle security external to the application being secured) is a very effective approach for enabling a single set of administrators to administer all security accesses through a single interface. External security provides consistency across all applications. It also provides separation of duties, as the people in charge of applications, databases, or other systems aren’t the same ones in charge of securing them.

Separation of duties is important. It keeps people honest. For example, separation prevents those in charge of applications, databases and systems from making self-interested changes to data. It also protects people who are doing the right thing. Without this separation, your best technologists will be under a cloud of suspicion when problems arise.

And yet, it’s surprising how many applications and databases are still secured using internal tables instead of deferring to external security.

Take a look at your own organization. Are there any applications or databases that don’t have all their security handled exclusively by your external security product on your mainframe? If so, it’s time to convert those applications to use the Application Programming Interfaces (APIs) in your external security instead of their internal tables.

Otherwise, that’s a loose end that auditors are likely to be concerned about.

Clean out obsolete user IDs and access—and keep them clean: When employees have been with one organization for several years, they often learn there are two ways to get things done— the official way and the way that works. Often, this back-door “way that works” involves the employee collecting access to numerous computer systems and resource permissions and not giving it back when his/her role changes.

But this subverts the way things are supposed to work, and can lead to all kinds of exposures.

This gets even worse when someone leaves the organization and no one is aware this person had more than one ID. In cases where departure is involuntary or under other unpleasant circumstances, a security exposure emerges.

Failure to fully track and maintain only those IDs and resource permissions that are current and appropriate is a major security loose end, and it’s all too common. However, given the solutions available today for provisioning, deprovisioning and cleanup, it’s also easily avoided.

Change utility passwords—and simplify future changes: Applications and other regular tasks are occasionally created using hard-coded passwords so an off-platform program can access data or applications on the mainframe in background mode. This also may have occurred because it seemed an acceptable idea two or three decades ago when a particular utility job was created for a specific ID. Or, perhaps a system has only one administrative ID, so everyone who administers uses the same password.

Whatever the reason, having a shared and/or unchanging password is a major security exposure. It not only provides an easy back door for anyone who wants to take an unauthorized stroll through the system, but it also makes it impossible to provide an audit trail of who made what changes to the system. And when those responsible are asked about this issue, they typically respond with “don’t worry, it’s never been a problem, and we need it like that for the system to work.”

Today’s mainframe external security makes such kludges unnecessary and helps eliminate a dangerous exposure.

Tighten controls on JCL libraries and started tasks: Started tasks are a primary way system tasks are defined on mainframes, such as those that run IBM’s z/OS. These tasks are initiated through a console command that invokes a PROC (procedure) stored in a system PROCLIB (a library of JCL procedures).

Of course, system tasks need a certain amount of security access in order to properly perform, so these started tasks need to be defined accordingly. That’s typically not an issue, but things become problematic when the following three items aren’t properly secured:

1. Access to system PROCLIBs: Started tasks are drawn from text-based JCL members of system PROCLIBs. So, it’s important that only authorized individuals have the ability to update them. Otherwise, someone could create a new PROC (depending on how generous your “generic” security is for undefined PROCs), or a phony alternate version of an established one, which could be run on the system if the following two conditions also are met.

2. Access permissions given to default and obsolete PROCs: When old, unused PROCs aren’t deleted from the security system, counterfeit versions could be made and stored in system PROCLIBs, allowing them to be invoked to perform arbitrary actions. In addition, if the default access for undefined started tasks is too permissive, a brand new PROC can be defined that also could do a great deal of damage.

3. Access to issue system console commands through “back-door” interfaces: While it’s possible to properly secure the back doors to issuing mainframe console commands, many mainframe sites haven’t completely done so. Experienced mainframe technologists often are able to issue system operator commands (e.g., to start up PROCs as systems started tasks) using these back doors without any security in place to prevent such actions.

Bring these together, and a Trojan Horse system task could be defined and initiated, creating devastating results for an organization.

Fixing Mainframe Security

For years, pundits have referred to the mainframe as a dinosaur. But instead of becoming extinct, dinosaurs grew wings and became today’s birds. And unless you just moved your last production application off platform and turned it off, your mainframe isn’t extinct either. In fact, it’s probably the anchor of your IT environment.

Understand the role of the mainframe today, where your business needs it to be, and how your staffing situation is going to change over the next five years. Look at your applications and databases. Are any of them still internally secured? Look at your external security product. Is it fully implemented and properly configured? Look at your IDs and accesses. Are they still in use, and should they be? And if you don’t have the time or expertise in-house, get help. If none of these exposures has become an incident yet, make sure that never happens.

Securing the Future of the Mainframe

Many new, emergent technologies, even operating systems, continue to become available as today’s mainframes take wing. Of course, each of these arrives with its own security challenges.

As an example, Linux can be run on Intel or on a mainframe, but it still has the same challenges, including the fact it doesn’t natively ship with external security. If you want it to run as a production environment, it’s up to your technologists and security administrative personnel to put external security in place.

Other emergent exposures that have occurred on other environments also can happen to the same technologies when they become available on the mainframe, whether you’re using SQL, Java, Web Services, or anything that requires a firewall. Examples include:

The good news is that with each new exposure, new security methods, technologies, and services emerge. However, it’s up to the organization to take advantage of these solutions.

Now is the time to get into good habits and insist on security at the beginning of each new initiative, not as an afterthought. So, take the time to sit down and review your mainframe environment’s security. By examining and cleaning up your exposures today, you’ll position your organization for a successful and secure tomorrow.

Welcome to the future!

This article had no comments at the time of this printout.