Cleaning House for the Next Generation: Security Minus Obscurity

by Reginald (Reg) Harbeck
April 1, 2006

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.