Residual data is one of the greatest security exposures we face. The tools we have to manage it often aren’t implemented. When a disk data set is erased, the pointers to the data are erased, but the data itself continues to exist (as residual data) on whatever part of the disk drive it was first allocated.

The risk is that someone allocating a data set on the same disk drive could allocate the same part of the disk drive and then be able to read the residual data there. If it includes sensitive information, that information can be copied or browsed by any TSO programmer.

For disk files, the security software has a feature that writes zeros over specified data sets before erasing the pointers to it. RACF calls this feature EOS or Erase-On-Scratch. ACF2 and TopSecret call it AUTO-ERASE. All three security packages let you apply this feature to just the data sets you specify.

For anyone doubting this is a serious risk, or is concerned about possible performance effects of this feature, IBM states (in the Security Server RACF System Programmer’s Guide):

“This [copying sensitive residual data] requires no exotic tools or insider knowledge and can be done quite easily using JCL and an IBM-provided utility such as IEBGENER.”

“If you are using the DDSR function of IBM's extended data facility product (IXFP), specifying erase-on-scratch has minimal impact because DDSR performs the erasure in the overwhelming majority of cases.”

“In those rare cases where the storage subsystem was not able to erase the data, DFSMS erases the data using the ERASE CCW. This is also faster than on older devices because it does not need to wait for disk rotation.”

To protect residual data, you need two things: a description of which data sets are sensitive and careful coordination with your systems programmers. The description of sensitive data sets should come from the application owners and the compliance department, since they’re the only ones with the knowledge of the business risk. Your protection of sensitive data won’t be complete unless they provide this description to security administration as a regular part of the application development and maintenance cycle.  

Systems programmers know that in the past the EOS or AUTO-ERASE feature caused performance problems. With the hardware improvements described previously by IBM, these performance problems shouldn’t recur. But your systems programmers will want their own solid evidence.

Systems programmers should be provided the resources to test this feature and its performance on their own. (For example, on a system used for testing new features, they might create a one-cylinder, a 10-cylinder, and a 100-cylinder data set. Then they erase the data sets and time it. Next, they turn on the EOS feature just for these data sets and repeat the creation/deletion/timing.)

System data sets have their own two sets of security requirements: one regarding updates and the other regarding read access. Updates to certain system data sets need to be carefully controlled, because anyone who can update them can add privileged programs to the system. A privileged program is one with privileges (such as Supervisor State) that let them bypass all the security on the system. The systems programming manager will want to be informed of every update to one of these data sets. To make this happen, you set the security software rules protecting them to cause logging of any updates. These data sets include the APF authorized libraries, the MVS parmlibs, and others.

READ access to certain other system data sets should be tightly restricted, since anyone who can read them might be able to learn passwords or other sensitive data. These include the security software data sets, the page files, the SMF data sets, and the spool (print queue) data set.  

You might think that the ability to read the security software data sets won’t let you learn passwords, since the passwords are encrypted. This isn’t true, since password cracker programs can learn passwords by brute force methods.

You might think the ability to read the SMF data sets won’t let you learn passwords, since passwords aren’t supposed to be recorded there. However, smart auditors have found that some users confuse their userid with their password. You can imagine how this results in the password being exposed in the userid field of the SMF record.

In the next column, we’ll cover tape data set security and how to know that your data set protection is “right.”