This article is aimed at security officers, technical support analysts, data processing managers, and anyone else who sets security policies. Technical detail is avoided in favor of an overview of what security features are available. Since Unisys has been responsive to customers' requests for new security features, we'll pay special attention to those recently implemented in System Base (SB) 5.
First, the maximum length of passwords has been limited to six characters. Since shorter passwords are more easily guessed, security experts recommend longer passwords, usually at least eight characters.
Second, the only edit of password quality has been a minimum length. The site could specify that, for example, all passwords be at least five characters. But OS 2200 could not edit the quality of those characters to ensure that users are not setting easily-guessed passwords such as those with repeating characters, all digits, or words from the dictionary.
Third, although OS 2200 can force users to change their passwords periodically, it keeps no history of previously-used passwords. A user may toggle his password between his date of birth and licence plate number, and the security officer can neither know about it nor stop it. Unisys has resisted implementing a password history section in each user's TSS record.
In SB 5R2 Unisys addresses all three restrictions with a single new feature--machine-generated passwords. This feature, which may be turned on via an OS 2200 configuration parameter, generates new passwords up to eighteen characters long (the site can control the maximum length). Instead of a hard to memorize random string of characters, machine-generated passwords are built from phonetic parts of the English language. For example, it might generate TUGRORK but it would never generate IQ5PIJD.
When a user changes her password, OS 2200 presents a candidate new password which she can either accept or reject. If the user rejects it, OS 2200 continues presenting candidates until she accepts one. Since the most easily memorized passwords are often the most easily guessed, and since there's no better way to compromise a password than to write it down, creating a truly secure password is difficult. Not allowing users to choose their own password is an open invitation for them to write it down. By allowing users to reject passwords they don't like, there is a much greater chance that they will wind up with one that is easy to memorize but difficult to guess.
If you think machine-generated passwords would be more secure than user-chosen ones and are still using Fundamental Security, get busy. The machine-generated password feature is available only in Security Option 1 (or higher) environments. (Fundamental Security sites can use a couple of other new features available in SB 5R2. You can now suspend a user-id after a defined period of inactivity, a given number of invalid sign-on attempts or password change warnings, or at the security officer's discretion. The security officer can later reinstate the suspended user-id.)
Fundamental Security by design does not do a good job protecting files. The main protection mechanisms are read/write keys and privacy. Keys suffer the same problems as do passwords: they are limited to six characters and are usually either easily guessed or difficult to memorize (and so are apt to be written down). And since batch jobs must access keyed files, the keys are coded in runstreams, which too often find their way into files that are not themselves protected by keys. Unless you've taken very special measures to protect your keys, an experienced 1100/2200 programmer can learn many of them in a matter of hours. Each read key he discovers allows him to read yet another file, in which he hopes to find more keys. If he manages to discover the keys to SYS$*DLOC$, then he can access any file. Since keys are often coded in many batch runstreams, they not easily changed and so are not often changed. This means that ex-employees may know some keys still in use.
Under Fundamental Security private files can be accessed only by those sharing the same account or project (depending on the setting of an OS 2200 configuration parameter). This is very rarely what's desired. Sometimes it's too secure, prohibiting accesses you would like to allow, such as public read access. Other times it's not secure enough because, for example, access is not restricted only to the user who created it.
Security Option 1 provides two general mechanisms to protect your files--Mandatory Access Control (MAC) and Discretionary Access Control (DAC). As befits its name, OS 2200 always performs MAC checks before granting file access. DAC checking is at the discretion of the owner (creator) of the file. In order to access a file, both MAC and DAC checks must be satisfied.
In Security Option 1, MAC is implemented with clearance levels. Each file inherits the user's clearance level at the time she catalogued the file (or the first file in the set for files with multiple cycles). A clearance level is a number from 0 to 63. The security officer assigns each user a minimum and maximum allowable clearance level and users can change to any level within this range with the @LEV command. To write or delete a file, the user be executing at exactly the same clearance level as the file. To read a file the user must be executing at a clearance level greater than or equal to the file's, and the file's clearance level must be within the range allowed to the user. Anyone can read files having a clearance level of zero.
You can see that clearance levels are best suited to environments where data access rules are very hierarchical, such as military ones. Users may frequently need to change their clearance level, so they must be trained to do so. Batch jobs may err if you change the clearance level of files they use. (Under Security Option 2, compartment sets provide non- hierarchical MAC file protection.)
You may find it virtually impossible to come up with a scheme of clearance levels that is simple to use and understand. This will depend on how you access files, rather than result from any deficiency in Unisys' clearance level implementation. You could choose to give all users a minimum and maximum clearance level of zero, which means all files they create will have clearance level zero. This would allow you to avoid training your users in the intricacies of clearance levels. Since MAC checks must always be satisfied when all files' clearance level is zero and all users execute at clearance level zero, you would then have to rely on DAC to enforce file security.
DAC is discretionary in the same way that Fundamental Security's keys and privacy are--the user who catalogues a file chooses how it is protected. The file can be public (available to anyone), private (available only to its owner), or semi- private (ACR-controlled). Since files are frequently shared by many users, but not by every user, semi-private access using Access Control Records (ACRs) is the most popular DAC file protection mechanism.
An ACR is a security rule that specifies who may access a file, how they may access (read, write, delete, execute), and when they may access (time of day). Each file has at most one ACR attached to it. Each ACR may be attached to many files. ACRs can use user-id, account, and project to state who may access files. A user can specify which ACR to attach to a file when she creates it (via a field on @CAT or @ASG) or later (via the FURPUR @CHG,K command).
Previously, the content of ACRs could not be changed. If an ACR needed to be updated, you would have to create a new one. You would then attach it to the files that had attached the old one. Since an ACR can be attached to hundreds of files, this was a maintenance nightmare. Because users frequently join and leave the organization or assume new responsibilities, some sites lessened this difficulty by never coding user-ids in ACRs. Grouping users by account or project and coding these in ACRs considerably reduced the maintenance required.
Beginning with SB 5R2, ACRs can be updated. This enhancement removes the most vexing restriction of Security Option 1 and makes it much easier to manage.
There is one variant approach to file access well worth considering. A Site Management Complex (SIMAN) screen enables the security officer to specify that an individual user can create only unowned files and that a particular ACR will be attached automatically. The security officer can create all the ACRs and decide which ACR each user must attach, based on the site's data access policies. Users can then create and access files without worrying about their security requirements. We might call this 'semi-discretionary access control' (although Unisys does not use this term).
Limiting users to clearance level zero and specifying an ACR that the system will automatically attached to files they create provides a file security environment very close to that implemented by many IBM mainframes sites using packages such as ACF2. File access policies are defined and implemented by the security officer and are transparent to users (except those who commit security violations, of course). If you wish to migrate to Security Option 1 while minimizing user training and maximizing central control, this approach might be for you.
Privileges are of two main types. Some represent particular functions or options on Executive Requests, such as the privileged functions of ER COM$ (console messages) or the update function of ER CONFIG$ (system configuration). The other type of privilege allows users to bypass specific security checks such as file privacy or clearance levels. Needless to say, security bypass privileges must be very carefully controlled.
In a Fundamental Security system, ERs and privileges are granted either to everyone or to the security officer only, and there is no way to change this. This often means ERs and privileges are granted to users who should not have them or are prohibited to users who should. For example, all users have access to TIP ERs, although many demand users will have no legitimate need for them. And only the master user-id has access to some ERs, such as ER SMOQUE$ (symbiont queue management) or ER SERVE$ (monitor services). Often demand users, particularly technical support users, will require access to these ERs, but there is no way to grant them under Fundamental Security. So you must either deny their request or allow them to use the master user-id, which of course can do anything.
Under Security Option 1 and above, a SIMAN screen allows you to grant ERs and privileges by user-id, thereby matching a user's power to his legitimate needs. Since this is done by user-id, it can be quite difficult to ensure that all users with common needs have identical ER and privilege profiles, and changing profiles is time-consuming. Someone after my own heart submitted a New Feature Suggestion (NFS) that Unisys simplify this by providing user-id groups. This NFS was on the Fall 1994 UNITE OS 2200 ballot. By the time you read this the results of the vote should be known. For more information see User Communication Form #26551749.