Operating a Multilevel Secure System

In an CA Top Secret MLS system, the console operator is considered trusted. Because operators perform tasks that alter the state of the system, their actions must be auditable. Console operators are required to log onto the system and undergo identification and authentication before performing any tasks. Because of the functions they perform, operators in an MLS system should log on with a SYSHIGH security label to ensure that they can issue commands to meet user requests.
Physical security should also be used to prevent other users from logging on to the system consoles. Even when not logged on, consoles display all message traffic.
Operator Consoles and Commands
Operator consoles can be forced to sign on before issuing commands. This is controlled by the LOGON keyword on the DEFAULT statement in the CONSOLxx member of SYS1.PARMLIB. The modes of operation are:
    In this mode, operators can log onto consoles if they choose to. The commands are validated and logged using the user ID with which they log on. Consoles that are not logged on use a special user ID of *BYPASS*.
    In this mode, operators must log onto consoles before they can enter commands. An exception is made for the master console, which will accept commands before the security system is up and able to process logons. (The exception is necessary to make it possible to enter system startup parameters.) Before security is initialized, only the master console can enter commands. After security is initialized, the entry area of all consoles (including the master) displays a formatted area where the operator can enter a user ID, password, group, and security label (SECLABEL). The operator must log on before any commands are accepted. When the operator logs off, the formatted logon prompt is once again displayed. When a console is varied offline, it is automatically logged of.
    In this mode, consoles are automatically logged on using a user ID that is equal to their console ID. This can provide logging and access control when physical security makes it possible to correlate a specific console and the operator that uses it.
In an MLS system, LOGON(REQUIRED), should be specified.
When an operator logs on to the console, a RACROUTE REQUEST=VERIFY call is issued to validate the identification and authentication (I&A) information entered by the operator. A SECTRACE for the logon looks like this:
When an operator enters a command, a RACROUTE REQUEST=AUTH call is issued, with a class of OPERCMDS.
System Initialization and Shutdown
The START and STOP commands can be protected using resource rules for the OPERCMDS class. Your site may want to generate a logging record when CA Top Secret is stopped or restarted.
When CA Top Secret is stopped, the console operator can vary the master console using the VARY MSTCONS command. Any activities performed by the operator while CA Top Secret is down are not logged. However, an SMF logging record is generated whenever CA Top Secret is started or stopped. This is displayed on the TSSUTIL report. The report should be reviewed for unscheduled CA Top Secret shutdowns.
System Clocks
The accuracy of the system clock can affect routine operations (such as scheduling tape erasures and archiving) and the accuracy of audit records. Ensure that authorized operators perform the setting of these clocks and that the operator commands used to set the clocks are protected.
In an CA Top Secret MLS system, the addressee, regardless of their security label, can receive a message sent by the console operator. The operator message is considered to be labeled SYSLOW. Since any user can send messages to the operator, operators must be careful not to echo information received in user messages.
System operators must not only be cleared to the system at a high level, they must also be cautioned to think twice before they send messages to users, to make sure they are not revealing classified information to those not cleared to see it. In MLS systems, if a resource rule was created for the SMESSAGE class, the operator may be prevented by DAC checking as well.
To send messages to users, the operator should send a public broadcast notice directed to all users. Because any user can view the information in the SYS1.BROADCAST data set, operators should use care to not disclose sensitive information about the activities they are performing in broadcast notices.
Example: messages
In this example, USERA, who is logged on with security label, SECRET, sends the following message to the console operator: “Will the system be up Saturday? We're attacking the Duchy of Grand Fenwick then, and we need the system.”
The operator is busy, and he sees the message just as it rolls off the screen. He misses the ACID, so he sends out a broadcast message: “Who was asking me about attacking Grand Fenwick?” This message goes out to all users, even those logged on below SECRET. The operator has just revealed the existence of the attack, which is classified.
Printed Matter
In an MLS system, operators, rather than end-users, should be responsible for separating and distributing printed classified output. There are procedures that operators in an MLS system should follow to manage deferred-printing mode page printers. Deferred-printing mode printers are those that select output from the JES2 output queues, rather than being under direct control of a particular job. This should be the only mode allowed for page printers.
Printing on all page printers is done through PSF. The PSF subsystem controls all paged, hardcopy printing in CA Top Secret. To reduce the chance of users tampering with separator pages, PSF ensures that all printing is identified with the user who submitted the print job. It does this by putting the user's ACID and an unforgeable, randomly assigned number on the beginning and ending separator pages for each job. Operators must check the numbers on the beginning and ending separator pages to ensure that they match and are authentic. If they do not, the output stack should be searched further for a matching ending page. Since the numbers are determined when the job is printed, rather than when it is run, the job cannot find out what the number is going to be to simulate authentic separator pages. To use security separator pages, replace the PSF-supplied default job header and trailer routines with PSF exit routines, APSUX01S and APSUX02S, from SYS1.SAMPLIB.
Although PSF enforces “print labeling”, the practice of putting security labels on all hard copy printed output; CA Top Secret does not support print labeling in an MLS environment.
Dumps and Traces
In an MLS system, the security administrator should assign security labels to all dumps and traces. The following rules should be followed for labeling dumps and traces:
  • If a dump data set contains system data, it should be labeled SYSHIGH
  • If the Generalized Trace Facility (GTF) creates the data set, or if the trace data set contains data from many address spaces, it should be labeled SYSHIGH.
  • If users, such as SYSDUMP, SYSABEND, and SYSMDUMP data sets, generate dumps these data sets should be labeled with the label of the job that generated the dump.
  • If the system fails, SMF records may be waiting to be written to DASD. To recover these records from a system dump, a user with a SYSHIGH label must do the following:
    • Allocate a VSAM data set to receive the SMF records.
    • Use the IPCS SMFDATA subcommand to recover the SMF records that remain in buffers.
    • WARNING! CA Top Secret does not assign a security label to all dumps and traces based on the original security label of the data. The security administrator must assign labels, as necessary.
The security administrator should assign security label SYSHIGH to any users who must work with system dump data sets so they are authorized to log on with the SYSHIGH label. Access rules for the dump and trace data sets should specify LOG to keep a record of the activity by these users.
Testing Devices and the System
Part of the operations of the system includes testing online devices and the integrity of the system. By running these tests periodically and ensuring that they perform satisfactorily, you ensure the hardware performs correctly and that the system, including the security-relevant code, works as coded. Several IBM tools are available for these purposes. The processor complex exerciser (PCX), channel subsystem exerciser (CSX), online test executive program (OLTEP), and online test standalone executive program (OLTSEP) are some of the tools that enable testing of various pieces of hardware such as the CPU and I/O devices.
Disk Pack Processing
In an MLS system, protection of disk data sets is provided by data set name.
An object does not retain its security label when transferred from virtual storage to a device attached to the system such as a DASD device.
Tape Processing
In an MLS system, access to tape data sets is validated based on whatever tape management system is use at your installation.
When a data set on tape is deleted, it is necessary for the operator to manually degauss (erase) the tape before it can be reissued for use by another data set. This is necessary to prevent data scavenging, where a user creates a tiny data set at the beginning of the tape, then reads the data that follows the data set to see the data from the previous user.
An object does not retain its security label when transferred from virtual storage to a device attached to the system, such as a tape volume.
Temporary Data Set Protection
In an MLS, during system failure, initiator failure, or system restarts, temporary data sets may be left on a DASD volume. These data sets are protected from unauthorized disclosure. A user with the NODESCHK attribute and a security label of SYSHIGH, should periodically scratch any residual temporary data sets on disk volumes. The SECURITY privilege and SYSHIGH label permit the user to access residual temporary data sets. However, these accesses are logged, and are reported in the TSSUTIL report.
Security Label Change Prevention
In an MLS system, even security-irrelevant requests may require that the operator be able to change the security label of a device for the request to be honored. CA Top Secret preserves the integrity of a site's security-labeling scheme by allowing only SCA's with the MLSADMIN administrative authority ACID record to change the security label of a data set.
Backing Up the CATop Secret Database
All CA Top Secret records are stored in the CA Top Secret security file database. The records stored in the database include:
  • ACID records
  • Access permissions
  • MLS-related records
Ensure the integrity of this database and ensure that it is backed up regularly. Be prepared with accurate, tested backup procedures to ensure the proper operation of the system.