In the October/November issue, we described how tape labels make security of tape data sets difficult because of two characteristics, that if not controlled, permit users to bypass all security for tape data sets: First, users can use Bypass Label Processing (BLP). Second, labels contain only the rightmost 17 characters of the dsname. This column continues our discussion, describing how Tape Management Software (TMS) solves these problems and provides additional security capability.
TMS gets control whenever a tape data set is opened. This gives it the opportunity to collect information about each tape data set, including the dsname, when it was created, how long it’s considered valid (that is, its retention period in days), the data set’s relative position on the tape, which tape it resides on, and whether it was opened for input or for output. The TMS can also invoke the security software to make access control decisions.
Well-known TMS packages include CA-1, CA-TLMS, IBM’s Removable Media Manager (RMM), and ASG’s Zeke and Zara. They all provide certain basic functionality, although each has its own unique characteristics. We will refer here to them all as TMS.
TMS maintains a database with one record for each tape cartridge in the tape library. This record contains the information about each data set on the tape. The TMS also records which ranges of volume serial numbers (the numbers that uniquely identify each tape cartridge) belong to your organization. This makes it possible for the TMS to identify any tape as either “local” (belonging to your organization) or “foreign.”
To solve the BLP problem, TMS software can call the security software to determine whether a user should be permitted to use BLP. This gives us access control over what would otherwise be another weakness in tape security. To control BLP, you can use the default provided by JES (not recommended), your security software directly, or tell the TMS to call the security software.
The TMS administrator controls this and other TMS options by settings in the TMS control file. Security administrators will need to work with TMS administrators to develop an integrated strategy for protecting tape data sets.
To solve the 17-character dsname problem, TMS compares the dsname on the DD card to the full 44-character dsname stored in its database, and rejects the request to open the data set if they don’t match.
Beyond solving these two problems, TMS gives us additional security capability. Imagine that your organization receives a tape from another organization. This tape will likely have a volume serial number outside that of your organization’s tapes. It will also likely have a data set with a dsname that doesn’t conform to your data set naming standards.
Imagine that your security software has been set to reject the opening of any data set whose name doesn’t have a matching data set rule in the security software database. (In RACF, this would result from PROTECTALL; in ACF2, from ABORT mode; and in TopSecret, from FAIL mode.)
This would cause the failure of any standard attempt to read the data set on this foreign tape because the dsname would have no matching rule in the security software database. Users trying to read this tape will then demand either the ability to use BLP, or privileges in the security software that give them total access to all data sets.
Your TMS will make this unnecessary, since it knows which ranges of volume serial number represent foreign tapes. It can call the security software, asking, “Can this user read this dsname?” If the response is, “The security software has no data set rule matching that dsname,” then the TMS can decide to grant the access for foreign tapes, but not for local ones. In this way, the TMS can relax the restriction that every dsname must be defined to the security software, but only in cases of foreign tapes.
Note: I will be taking a break from my column while I write a series of articles on cross-platform security (the first article appears in this issue). This column will return once we conclude the series, continuing our discussion of tape data set security.