Configuring the Safeguard Subsystem
Safeguard software was developed to enhance the security provided by the Guardian system. It provides more comprehensive security. Safeguard software works with the Guardian environment to apply more extensive and more specific security controls.
Safeguard and Guardian Compared
| Guardian System | Safeguard System Without OBJECTTYPE | Safeguard System With OBJECTYPE | |
|---|---|---|---|
| Default file security | User with DEFAULT PROGRAM access | User's Group Manager User Record Owner SUPER.SUPER (2) User | |
| Default subvolume | User with DEFAULT PROGRAM access | User's Group Manager User Record Owner SUPER.SUPER (2) User | |
| Aliases supported | No. | Yes, for auditing | |
| Who can add a user | SUPER.SUPER Group Managers | User's Group Mgr. SUPER.SUPER.(2) | OBJECTTYPE Record members with CREATE SUPER.SUPER (2) |
| Who can alter user information | N/A | SUPER.SUPER.(2) User Record Owner | |
| Who can Change Password | User | User | |
| Auditing | No | Yes | |
| Terminal Control | No | Yes | |
| Objects protected | Diskfiles Processes, Subprocesses | Volumes , Subvolumes , Devices, | |
| Objects with configurable security | Diskfiles | Volumes, Subvolumes, Devices, | |
| Who can ADDdiskfile security | Owner | File owner | OBJECTTYPE Record members with CREATE SUPER.SUPER (2) |
| Who can ALTERdiskfile security | Owner | Protection Record Owner. Primary Owner's Grp Mgr. Secondary Owner(s) SUPER.SUPER(2) | |
| Process Control | Owner | Protection Record members granted R,W,P,C | |
| Device Control | None. | Protection Record members granted R,W |
1 -If PASSWORD program binding changes have not been made to force entry of old password before entering new password.
2 -If SUPER.SUPER is configured as UNDENIABLE
Safeguard controls fall into three categories:
User authentication
Authorization of object access attempts
Auditing
Configuration within each of these categories is affected by global parameters and attributes within individual Protection, User or Alias Records.
Safeguard Global Configuration
The following aspects of Safeguard software can be configured globally:
User authentication controls
Password controls
Priority of Protection Records between DEVICES and SUBDEVICES
Priority of Protection Records between PROCESSES and SUBPROCESSES
Priority of Protection Records between VOLUMES, SUBVOLUMES, and DISKFILES
Auditing, both system-wide and for individual objects
Logon controls
The Command Interpreter to be started after a user logs on at a Safeguard terminal
Exclusive access for the user logged on at a Safeguard terminal
Client subsystem auditing
System-level warning mode
SUPER.SUPER Undeniable
Local SUPER.SUPER is made undeniable with an entry in the CONFTEXT file.
When Safeguard is configured so that SUPER.SUPER is undeniable, Safeguard software ignores explicit denials of access authorities for SUPER.SUPER.
This parameter takes effect when the system is cold loaded with the OSIMAGE file that was produced from the CONFTEXT file containing this parameter. See the Security Considerations of Safeguard Software Installation subsection immediately above for more information.
BP-SAFEGARD-CONFIG-01 Safeguard should be configured SUPER.SUPER UNDENIABLE so that, in an emergency, SUPER.SUPER can perform any required task, including modifying a Safeguard Protection or User Record.
RISK Users logged on as SUPER.SUPER, or as an alias to SUPER.SUPER, will be able to alter the Safeguard configuration, possibly compromising system security.
To mitigate the risks of SUPER.SUPER UNDENIABLE:
AP-ADVICE-SAFEGARD-01 Do not allow users to logon as SUPER.SUPER except in emergencies or for pre-approved maintenance such as operating system upgrades.
3P-ACCESS-SAFEGARD-01 Use a third party access control product to grant users granular access to SUPER.SUPER privileges. If a third party access control product is in use:
3P- ACCESS-SAFEGARD-01A If users are granted access to a SAFECOM running as SUPER.SUPER, it is recommended that the ADD command be denied to prevent any Protection, User or Alias Records from being added (and therefore owned) by SUPER.SUPER, which would prevent the Security Admin userid the ability to even see the added records.
3P- ACCESS-SAFEGARD-01B If the system management group needs to add Safeguard records, provide them a secure SAFECOM running as the Security Admin userid.
AP-ADVICE-SAFEGARD-02 Whether or not SUPER.SUPER is UNDENIABLE and whether or not a third party access control product is in use, a Safeguard audit report, which includes the addition or alteration of any Safeguard objects, should be reviewed daily.
Safeguard Global Authentication Controls
The following global attributes are discussed in User Administration in Part Three.
BP-SAFEGARD-GLOBAL-53 BLINDLOGON = ON
BP-SAFEGARD-GLOBAL-54 NAMELOGON = ON
BP-SAFEGARD-GLOBAL-55 TERMINAL-EXCLUSIVE-ACCESS = OFF
BP-SAFEGARD-GLOBAL-03 AUTHENTICATE-FAIL-FREEZE = OFF
BP-SAFEGARD-GLOBAL-02 AUTHENTICATE-FAIL-TIMEOUT = 60 seconds
BP-SAFEGARD-GLOBAL-01 AUTHENTICATE-MAXIMUM- ATTEMPTS = 3
Safeguard Global Password Controls
The following global attributes are discussed in Password Management in Part Three.
BP-SAFEGARD-GLOBAL-06 PASSWORD-ENCRYPT = ON
BP-SAFEGARD-GLOBAL-05 PASSWORD-HISTORY = 10
BP-SAFEGARD-GLOBAL-07 PASSWORD-MINIMUM-LENGTH = 6 to 8
BP-SAFEGARD-GLOBAL-04 PASSWORD-REQUIRED = OFF
BP-SAFEGARD-GLOBAL-09 PASSWORD-EXPIRY-GRACE = between 7 and 15
BP-SAFEGARD-GLOBAL-08 PASSWORD-MAY-CHANGE = 7
Safeguard Global Warning-Mode Controls
The following global attributes determine whether or not Safeguard software is in Warning Mode and how it will behave when it is. These are discussed in the Warning Mode section of this section.
BP-SAFEGARD-GLOBAL-10 WARNING-MODE = OFF
BP-SAFEGARD-GLOBAL-11 WARNING-FALLBACK-SECURITY = GUARDIAN
Safeguard Global Device Controls
The following global attributes determine how Device Protection Records will be processed . These are discussed in the Authorization and Object Security in Part Five.
BP-SAFEGARD-GLOBAL-12 DIRECTION-DEVICE parameter should be SUBDEVICE -FIRST
BP-SAFEGARD-GLOBAL-13 CHECK-DEVICE parameter should be ON
BP-SAFEGARD-GLOBAL-14 COMBINATION-DEVICE parameter should be FIRST-ACL
BP-SAFEGARD-GLOBAL-15 CHECK-SUBDEVICE parameter should be ON
BP-SAFEGARD-GLOBAL-16 ACL-REQUIRED-DEVICE parameter should be OFF
Safeguard Global Process Controls
The following global attributes determine how Process Protection Records will be processed. These are discussed in Securing Processes with the Safeguard Subsystem in Part Five.
BP-SAFEGARD-GLOBAL-17 DIRECTION-PROCESS parameter should be SUBPROCESS-FIRST
BP-SAFEGARD-GLOBAL-18 CHECK-PROCESS parameter should be ON
BP-SAFEGARD-GLOBAL-19 COMBINATION-PROCESS parameter should be FIRST-ACL
BP-SAFEGARD-GLOBAL-20 CHECK-SUBPROCESS parameter should be ON
BP-SAFEGARD-GLOBAL-21 ACL-REQUIRED-PROCESS parameter should be OFF
Safeguard Global Diskfile Controls
The following global attributes determine how disk file access attempts will be processed. These are discussed in the Securing Diskfiles with Safeguard Part Five.
BP-SAFEGARD-GLOBAL-22 DIRECTION-DISKFILE parameter should be FILENAME-FIRST
BP-SAFEGARD-GLOBAL-23 CHECK-VOLUME parameter should be OFF
BP-SAFEGARD-GLOBAL-24 COMBINATION-DISKFILE parameter should be FIRST-ACL
BP-SAFEGARD-GLOBAL-25 CHECK-SUBVOLUME parameter should be ON
BP-SAFEGARD-GLOBAL-26 ACL-REQUIRED-DISKFILE parameter should be OFF
BP-SAFEGARD-GLOBAL-27 CHECK-FILENAME parameter should be ON
BP-SAFEGARD-GLOBAL-28 CLEARONPURGE-DISKFILE parameter should be OFF
Safeguard Global CMON Controls
The following global attributes determine how Safeguard software will interact with CMON. These are discussed in the CMON in Part Four.
RISK Safeguard software will not consult $CMON when starting a Safeguard terminal TACL if CMON is OFF.
RISK When Safeguard processes a logon and the Safeguard global CMON is set to OFF, then neither LOGON nor LOGOFF messages are sent to $CMON.
BP-SAFEGARD-GLOBAL-50 CMON parameter should be ON
BP-SAFEGARD-GLOBAL-51 CMONERROR parameter should be ACCEPT.
BP-SAFEGARD-GLOBAL-52 CMONTIMEOUT parameter value depends on the speed of the system or = 30 sec
RUN messages that are sent to $CMON will be processed normally by CMON, regardless of the Safeguard CMON settings.
Safeguard Global Command Interpreter Controls
The following Command Interpreter (CI) attributes determine whether or not Safeguard software will start a Command Interpreter after it has authenticated the user at a Safeguard-controlled terminal and how that program will be configured. The defaults should be used if Safeguard controlled terminals are not implemented.
These globals are discussed in Managing Userids with the Safeguard Subsystem in Part Three.
CI-PROG
CI-LIB
CI-CPU
CI- NAME
CI-SWAP
CI-PRI
CI-PARAM-TEXT
Safeguard Global Audit Controls
The following Audit Control attributes determine whether or not attempts to ACCESS the object the record is protecting will be audited .
These globals are discussed in Managing Userids with the Safeguard Subsystem in Part Three.
BP-SAFEGARD-GLOBAL-34 AUDIT-AUTHENICATE-PASS should be ALL
BP-SAFEGARD-GLOBAL-35 AUDIT-AUTHENTICATE-FAIL should be ALL
BP-SAFEGARD-GLOBAL-29 AUDIT-CLIENT-SERVICE should be OFF
These globals are discussed in Managing Devices with the Safeguard Subsystem in Part Five.
BP-SAFEGARD-GLOBAL-38 AUDIT-DEVICE-ACCESS-PASS should be NONE
BP-SAFEGARD-GLOBAL-39 AUDIT-DEVICE-ACCESS-FAIL should be ALL
BP-SAFEGARD-GLOBAL-40 AUDIT-DEVICE-MANAGE-PASS should be ALL
BP-SAFEGARD-GLOBAL-41 AUDIT-DEVICE-MANAGE-FAIL should be ALL
These globals are discussed in Managing Diskfiles with the Safeguard Subsystem in Part Five.
BP-SAFEGARD-GLOBAL-46 AUDIT-DISKFILE-ACCESS-PASS should be NONE
BP-SAFEGARD-GLOBAL-47 AUDIT-DISKFILE-ACCESS-FAIL should be ALL
BP-SAFEGARD-GLOBAL-48 AUDIT-DISKFILE-MANAGE-PASS should be ALL
BP-SAFEGARD-GLOBAL-49 AUDIT-DISKFILE-MANAGE-FAIL should be ALL
These globals are discussed in Managing Objects with the Safeguard Subsystem in Part Five.
BP-SAFEGARD-GLOBAL-30 AUDIT-OBJECT-ACCESS-PASS should be NONE
BP-SAFEGARD-GLOBAL-31 AUDIT-OBJECT-ACCESS-FAIL should be ALL
BP-SAFEGARD-GLOBAL-32 AUDIT-OBJECT-MANAGE-PASS should be ALL
BP-SAFEGARD-GLOBAL-33 AUDIT-OBJECT-MANAGE-FAIL should be ALL
These globals are discussed in Managing Processes with the Safeguard Subsystem in Part Five.
BP-SAFEGARD-GLOBAL-42 AUDIT-PROCESS-ACCESS-PASS should be NONE
BP-SAFEGARD-GLOBAL-43 AUDIT-PROCESS-ACCESS-FAIL should be ALL
BP-SAFEGARD-GLOBAL-44 AUDIT-PROCESS-MANAGE-PASS should be ALL
BP-SAFEGARD-GLOBAL-45 AUDIT-PROCESS-MANAGE-FAIL should be ALL
These globals are discussed in Managing Userids with the Safeguard Subsystem in Part Three.
BP-SAFEGARD-GLOBAL-36 AUDIT-SUBJECT-MANAGE-PASS should be ALL
BP-SAFEGARD-GLOBAL-37 AUDIT-SUBJECT-MANAGE-FAIL should be ALL
The Concept of Ownership in the Safeguard Subsystem
Safeguard software introduces a concept of a Protection Record owner for all types of records.
RISK Safeguard software will not allow any userid to manage any Protection Record, User Record or Alias Record that the userid doesn't own, unless the userid is SUPER.SUPER and SUPER.SUPER is undeniable. The record owner's Group Manager can also manage the record.
RISK Even the INFO command will not display information about Protection Records, Users or Aliases that the userid doesn't own, which can essentially "mask" records.
There are two types of owners :
Primary Owners
Secondary Owners
Primary Owner
The Primary Owner is the owner of the Protection or User Record. The Primary Owner can do anything to the record.
The Primary Owner can be a local user or network user.
AP-ADVICE-SAFEGARD-03 If the Security Staff manages Safeguard software on more than one node, it is recommended that the Primary Owner of all userids be entered as a network user. A network owner can perform administrative tasks across the network.
 |
GROUP.USER USER-ID OWNER LAST-MODIFIED LAST-LOGON STATUS FTP.MANAGER 200,255 253,1 17OCT02, 10:14 17OCT02, 10:15 THAWED
| |
Example 1 shows a user record with a local owner.
| |
5> Safecom info user 222,77 GROUP.USER USER-ID OWNER LAST-MODIFIED LAST-LOGON STATUS ABCO.BRYAN 222,177 \*.253,1 12APR02, 11:00 21JAN03, 9:58 THAWED
| |
Example 2 shows a user record with a network owner.
Secondary Owner(s)
Secondary ownership is defined by the owner access (O) authority in the ACL of a Protection Record.
The Primary Owner can add Secondary Owners to any Object Protection Record's ACL.
Secondary owners can do anything that the Primary Owner is permitted to do. They are equal, in every way, to the Primary Owner.
| |
$DATAA.BRYAN DATAFILE 5NOV02, 9:22 \*.253,1 THAWED \*.122,177 R,W,E,P, O GROUP \*.00122 R GROUP \*.00300 R
| |
This example shows a DISKFILE Protection Record. The Primary Owner is network user 253,1. Network user 122,177 is a Secondary Owner.
Ownership Recommendations
In order to simplify Safeguard management, it is highly recommended that a single user owns all the Protection Records.
AP-ADVICE-SAFEGARD-04 All Protection Records, all User Records and all Alias Records should be owned by a single Security Manager userid. This is the only way to guarantee that the Security Manager can view all existing User, Alias and Object Protection Records.
Safeguard Objects
Users, Diskfiles, Devices and Processes are commonly referred to as OBJECTs on the HP NonStop server. Safeguard software secures the following objects:
USER
ALIAS
GROUP
VOLUME
SUBVOLUME
DISKFILE
PROCESS
SUBPROCESS
DEVICE
SUBDEVICE
OBJECTTYPE
Each type of object can be secured via Protection Records. That is, diskfiles may be secured with DISKFILE Protection Records, VOLUME Protection Records and SUBVOLUME Protection Records. Processes are secured with PROCESS and SUBPROCESS Records.
This Protection Record determines:
Who can MANAGE the object, that is ALTER or DELETE the object's Protection Record
Who can ACCESS the object, that is READ, WRITE, EXECUTE or PURGE it
Object Protection Records
Protection Records for the various types of Objects contain several common attributes. They are:
Owner
Access Control List (ACL)
Status
Audit Configuration
These common attributes are discussed here. The attributes specific to certain types of objects will be discussed in detail in the appropriate sections. For example, DISKFILE Protection Records have several unique attributes. These will be discussed in Securing Diskfiles with the Safeguard Subsystem in Part Five.
Owner
All OBJECTTYPE Protection Records have a Primary Owner. They may also have one or more optional Secondary Owners.
Access Control List (ACL)
The ACL portion of the Protection Record is where users are granted or denied specific access privileges to the underlying object.
When an attempt is made to access a protected object, Safeguard software checks the Protection Record(s) for the target object to determine whether the user or File- Sharing Group (identified by the PAID) has the required authority to access the object. Some types of objects, such as files, may be protected by more than one Safeguard Rule.
The privileges relevant to the various types of objects vary, as shown in the table below.
| Operations / Privileges Granted in Safeguard Protection Records | ||||||
|---|---|---|---|---|---|---|
| Operation | Volume & | Subvolume | Process &Subprocess | Device &Subdevice | Objecttype | Security-Grps |
| READ | OPEN for input | OPEN for input | OPEN for input and output | OPEN for input and output | ||
| WRITE | OPEN for input and output | OPEN for input and output | OPEN for input and output | OPEN for input and output | ||
| EXECUTE | EXECUTE the object file | EXECUTE any object file not protected by another record | EXECUTE the restricted Safeguard commands | |||
| PURGE | PURGE the file | PURGE any file not protected by another record | STOP the process | |||
| CREATE | *1 | CREATE a file in any subvol not protected by a SUBVOL Record | CREATE a process with a given name. | CREATE records for individual objects of the same Object Class | ||
| OWN | ALTER or PURGE the Record | ALTER or PURGE the Record | ALTER or PURGE the Record | ALTER or PURGE the Record | ALTER or PURGE the Objecttype Record | ALTER or PURGE the Security Group Record |
*1 CREATE authority for a disk file has no meaning unless the PERSISTENT attribute is ON for that file name.
RENAMING Considerations
The RENAME operation requires special evaluation of access authorities as shown in the table below.
| Access Authorities Required to Rename a File | |||||
|---|---|---|---|---|---|
| Current File Name | New File Name | Result | |||
| Safeguard Record Exists? | Safeguard Purge Allowed? | Guardian Purge Allowed? | Safeguard Vol/Subvol/ Disk Record Exist? | Safeguard Create Allowed? | Rename Allowed? |
| No | - | Yes | No | - | Yes |
| No | - | Yes | Yes | Yes | Yes |
| No | - | Yes | Yes | No | No |
| No | - | No | - | - | No |
| Yes | Yes | - | No | - | Yes |
| Yes | Yes | - | Yes | Yes | Yes |
| Yes | Yes | - | Yes | No | No |
| Yes | No | - | - | - | No |
The PERSISTENT Attribute and Renaming:
If the original file does not have a PERSISTENT Protection Record, the new file assumes the original file's Protection Record.
If the original file has a PERSISTENT Protection Record, the new file does not assume the original file's Protection Record.
If the new file name has a PERSISTENT Protection Record, the new file assumes the PERSISTENT Record.
Defining Users In Protection Record ACLs
Only userids and File-Sharing Groups can be used in Safeguard Protection Records. Aliases cannot be used in Safeguard Protection Records.
RISK Aliases gain all the access authority defined for their underlying userid or File-Sharing Group membership.
3P-SAFEGARD-CONFIG-01 Instead of aliases, a third party access control product should be used to grant granular access to the privileges of functional and application userids.
Remote access is defined as an access attempt made by a user authenticated on a different node. If remote access is appropriate for a given object, the users must be defined as network users ( \*. ) when granting privileges in the ACL or Safeguard software will deny the access requests from another node.
Users defined as network users are automatically granted the appropriate local access privileges as well.
RISK Ownership \* gives global rights to all nodes.
3P-OBJECT-ACCESS-01 A third party tool can provide additional security to identify and restrict \* for specific nodes.
Audit Parameters
The individual Protection Records for each object determines whether or not attempts to ALTER or DELETE the Protection Record (i.e., MANAGE) will be audited and whether or not attempts to ACCESS the object the record it is protecting will be audited. See the following discussion for the variations of AUDIT-ACCESS and AUDIT-MANAGE parameters that apply to the object types.
AUDIT-ACCESS-{PASS FAIL}
The AUDIT-ACCESS-PASS and AUDIT-ACCESS-FAIL attributes determine whether or not Safeguard software will write audits when someone attempts to access the object to which the Protection Record applies.
The valid entries are:
| ALL | All successful / failed attempts to access the protected object will be audited. |
| NONE | No successful / failed attempts to access the protected object will be audited. |
| LOCAL | Only successful / failed local attempts to access the protected object will be audited. |
| REMOTE | Only successful / failed remote attempts to access the protected object will be audited. |
AUDIT-MANAGE{-PASS -FAIL}
The AUDIT-MANAGE-PASS and AUDIT-MANAGE-FAIL attributes determine whether or not Safeguard will write audits when someone attempts to ALTER or DELETE the particular Protection Record.
The valid entries are:
| ALL | All successful / failed attempts to ALTER or DELETE the object's Protection Record will be audited. |
| NONE | No successful / failed attempts to ALTER or DELETE the object's Protection Record will be audited. |
| LOCAL | All successful / failed local attempts to ALTER or DELETE the object's Protection Record will be audited. |
| REMOTE | All successful / failed remote attempts to ALTER orDELETE the object's Protection Record will be audited. |
Safeguard OBJECTTYPES
Each type of object has an associated OBJECTTYPE Protection Record that controls who is allowed to CREATE Protection Records for individual objects of that particular Object Class. For example, the ability to CREATE Protection Records for diskfiles is controlled by the DISKFILE OBJECTTYPE.
The Object Class is made up of all objects of the type protected by an OBJECTTYPE Protection Record, for example diskfiles make up the Object Class of the DISKFILE OBJECTTYPE.
Safeguard software supports Protection Records for the following OBJECT- TYPEs:
USER (includes aliases)
VOLUME
SUBVOLUME
DISKFILE
PROCESS
SUBPROCESS
DEVICE
SUBDEVICE
OBJECTTYPE
Each OBJECTTYPE Protection Record will be discussed in the appropriate section, for example, the DISKFILE OBJECTTYPE will be discussed in Securing Diskfiles with the Safeguard Susbsystem in Part Five.
OBJECTTYPE OBJECTTYPE
The OBJECTTYPE Protection Records are in themselves "pseudo-objects," therefore, an additional OBJECTTYPE record exists to control the creation of new OBJECTTYPE Protection Records. This is called the OBJECTTYPE OBJECTTYPE record.
Only the owner and other users granted CREATE (C) authority on the OBJECTTYPE OBJECTTYPE ACL (if present) can create other OBJECTTYPE records.
Only the owner and other users granted OWNER (O) authority on the OBJECTTYPE OBJECTTYPE ACL can MANAGE the OBJECTTYPE OBJECTTYPE Protection Record.
BP-SAFEGARD-CONFIG-02 The OBJECTTYPE OBJECTTYPE Protection Record should be used to restrict who can create the remaining OBJECT- TYPE Records.
AP-ADVICE-SAFEGARD-05 In general, only members of the Security Group should be authorized to CREATE, ALTER or DELETE Safeguard Protection Records.
| Note | The OBJECTTYPE DISKFILE has no effect on the Guardian default protection for a user's disk files. It only controls who can execute the Safecom ADD DISKFILE command to add a Diskfile Protection Record. |
OBJECTTYPE Protection Records
OBJECTTYPE Protection Records determine who can MANAGE the particular OBJECTTYPE Protection Record, that is, ALTER or DELETE the Protection Record and who can CREATE or MANAGE Protection Records for individual objects of the same Object Class.
When a user attempts an ADD command (for example, ADD DISKFILE), Safeguard software first checks for the presence of a Protection Record for the corresponding OBJECTTYPE.
If no record exists, Safeguard software proceeds according to the default rules shown in the Table Who Can Place Objects Under Safeguard Control .
If a record exists for the corresponding OBJECTTYPE, Safeguard software consults its ACL and makes the appropriate ruling :
If the user has CREATE authority on the OBJECTTYPE ACL, the ADD succeeds.
If the user doesn't have CREATE authority on the OBJECTTYPE ACL, the ADD command fails.
Each OBJECTTYPE Protection Record contains the following attributes:
Owner
ACL
Status
Audit Configuration
OBJECTTYPE Ownership
OBJECTTYPE Protection Records respect the standard Primary and Secondary ownership privileges and processing.
RISK In addition to the Primary Owner, the Primary Owner's group manager, and local SUPER.SUPER, any user ID that has an ACL entry grantingOWNER authority can also modify the OBJECTTYPE Protection Record.
Who can Manage Object-Class Protection Records?
The following table summarizes who is allowed to CREATE, ALTER or DELETE Protection Records for the relevant Object-class.
| Who Can Place Objects Under Safeguard Control | ||
|---|---|---|
| OBJECTTYPE | Who Can Create ACLs Without Objecttype Records? | Who Can Create ACLs With Objecttype Records |
| USER | Local SUPER.SUPER and local grp mgrs | Only userids specifically granted CREATE privileges and SUPER.SUPER if not undeniable |
| ALIAS | Local owner of the underlying ID or the owner's Grp mgr or SUPER.SUPER | Only userids specifically granted OWN and CREATE privileges and the OBJECTTYPE Record's Primary Owner and his Group Manager. |
| GROUP | Local SUPER group | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| OBJECTTYPE | Local SUPER group | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| VOLUME | Local SUPER group | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| SUBVOLUME | Any local user | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| DISKFILE | Local file owner Local SUPER.SUPER Owner's local grp mgr | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| PROCESS | Any local user | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| SUBPROCESS | Any local user | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| DEVICE | Local SUPER group | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| SUBDEVICE | Local SUPER group | Only userids specifically granted CREATE privileges and SUPER SUPER if not deniable |
| SECURITY GROUPS | Local SUPER group | Members of the SECURITY-ADMINISTRATOR SECURITY GROUP |
| TERMINAL | Local SUPER group | Members of the SECURITY-ADMINISTRATOR SECURITY GROUP |
| SEEP | Local SUPER group | Members of the SECURITY-ADMINISTRATOR SECURITY GROUP |
OBJECTTYPE ACL
The following access authorities can be granted to users and user groups:
CREATE ADD a Protection Record for an object in the Object-Class
OWNER ALTER or DELETE the OBJECTTYPE Protection Record itself
BP-SAFEGARD-CONFIG-03 All OBJECTTYPE Protection Records should be owned by a single Security Manager userid.
OBJECTTYPE Status
Each OBJECTTYPE Protection Record can be FROZEN or THAWED. Freezing an OBJECTTYPE Protection Record temporarily suspends the authorities granted by the record's ACL. While the OBJECTTYPE Protection Record is frozen, only the following users can CREATE Protection Records for the relevant Object Class:
The Primary Owner of the OBJECTTYPE Protection Record
The Primary Owner's group manager
The Primary or Secondary Owner of an individual Object class Protection Record
Local SUPER.SUPER
For example, if the VOLUME OBJECTTYPE Protection Record is frozen, the Primary Owner of the Protection Record for $SYSTEM can alter the $SYSTEM Pro-Local SUPER group tection Record, but could not add a new Protection Record for the $USER volume, unless he was also the Primary Owner of the VOLUME OBJECTTYPE Protection Record (or that Primary Owner's Group Manager or SUPER.SUPER).
RISK When an OBJECTTYPE Protection Record is FROZEN, authorities granted to users in the OBJECTTYPE's ACL are changed. Users granted CREATE but not OWNERSHIP authority cannot create new PROCESS Protection Records while the PROCESS OBJECTTYPE is FROZEN.
Consider the following example:
| |
OBJECTTYPE PROCESS 253,1 O 220,250 C
| |
When the PROCESS OBJECTTYPE shown above is THAWED, user 220,250 can CREATE Protection Records for individual processes, but user 253,1 cannot.
When the PROCESS OBJECTTYPE shown above is FROZEN, user 220,250 cannot CREATE Protection Records for individual processes, but user 253,1 can.
OBJECTTYPE Audit Attributes
OBJECTTYPE Audit Attributes follow the same standards as other Protection Record Audit Attributes. The OBJECTTYPE Audit Attributes are:
AUDIT-ACCESS-PASS
AUDIT-ACCESS-FAIL
AUDIT-MANAGE-PASS
AUDIT-MANAGE-FAIL
AUDIT-ACCESS{-PASS -FAIL}
The AUDIT-ACCESS-PASS and AUDIT-ACCESS-FAIL attributes determine whether or not Safeguard software will write audits when someone attempts to CREATE a Protection record for an object in the relevant object class.
The valid entries are:
| ALL | All successful / failed attempts to CREATE a Protection Record for an object in the relevant object-class will be audited. |
| NONE | No successful / failed attempts to CREATE a Protection Record for an object in the relevant object-class will be audited. The default value is NONE. |
| LOCAL | Only successful / failed local attempts to CREATE a Protection Record for an object in the relevant object-class will be audited. |
| REMOTE | Only successful / failed remote attempts to CREATE a Protection Record for an object in the relevant object-class will be audited. |
AUDIT-MANAGE{-PASS -FAIL}
The AUDIT-MANAGE-PASS and AUDIT-MANAGE-FAIL attributes determine whether or not Safeguard software will write audits when someone attempts to ALTERor DELETE this OBJECTTYPE Record.
The valid entries are:
| ALL | All successful / failed attempts to ALTER or DELETE this OBJECT- TYPE Record will be audited. |
| NONE | No successful / failed attempts to ALTER or DELETE this OBJECT- TYPE Record will be audited. The default value is NONE will be audited. |
| LOCAL | Only successful / failed local attempts to ALTER or DELETE this OBJECTTYPE Record will be audited. |
| REMOTE | Only successful / failed remote attempts to ALTER or DELETEthis OBJECTTYPE Record will be audited. |
Non-Object Safeguard Entities
Besides the Protection Records for all types of objects, Safeguard includes four other entities:
Audit Pools
Security Groups
Terminal Definition Records
Security Event Exit Processes (SEEPs)
| Who Can Create/Manage Non-Object Safeguard Entities | ||
|---|---|---|
| OBJECTTYPE Who Can Create or Alter Without | OBJECTTYPE Records? | Who Can Create or Alter With OBJECTTYPE Records |
| Audit Service | Local SUPER group | Members of the |
| Security Groups | Local SUPER group | Members of the |
| Terminals | Local SUPER group | Members of the |
| SEEPs Members of the | Local SUPER group | |
Configuring Safeguard Audit Pools
Audit records are written to the Audit Trail as they are received by the Safeguard Audit Service. The Audit Trail is composed of one or more Audit Pools. The term Audit Pool refers to the subvolume where the audit files reside. The Audit Pool name is always the same as the subvolume name.
By default, Safeguard software creates the current Audit Pool in $SYSTEM.SAFE.
BP-SAFEGARD-CONFIG-04 The Safeguard audit trail should be moved off $SYSTEM to another, less busy, volume.
The first file in an audit pool will be named A0000001; the second file, A0000002, etc. Safeguard software configures all the files at once, then writes to each one until it fills up. Once a file is full, Safeguard software opens the next file in the series. When the last file is full, Safeguard software's behavior is determined by the AUDIT SERVICE RECOVERY setting described below.
The Safeguard Audit Service can maintain multiple Audit Pools, but only one can be active at a time.
Determining the Size of Audit Pools
The size of an Audit Pool is determined by the number of individual files it will contain and the size of the files. These are configured using the AUDIT POOL command, which determines:
MAXFILES
EXTENTSIZE
MAXEXTENTS
Once these values are entered, the disk space is allocated and the files created.
MAXFILES
The MAXFILES parameter determines the maximum number of files that will be allocated to the Audit Pool.
The default value is 2 files.
EXTENTSIZE
The EXTENTSIZE parameter determines the space on a disk allocated for a file. These parameters set the size of the first and secondary extents, in 2048- byte pages.
The default value is 128 pages.
MAXEXTENTS
The MAXEXTENTS parameter determines the maximum number of disk file extents for each audit file.
The default value is 16 extents.
Sizing the Audit Files
The length of time that the Corporate Security Policy and Standards requires that Safeguard audits must be saved online will determine the number of Audit Pools required and the size and number of the files in each Audit Pool.
The method of generating Safeguard audit reports will have an impact on the size of Safeguard audit files. In general, the smaller the file, the faster a report can be generated, but many products, including Safeart, the audit tool provided by HP, can only generate a report on one audit file at a time. If research is needed for an event in a time period that spans two audit files, two reports must be run, one per audit file.
Many companies size the files so that one file will contain approximately one day's audit. Some size the files for a week's worth of audit. Some companies 'manually' roll the files at midnight every night, whether the files are full or not.
Some companies have a single Audit Pool, some use multiple audit pools as a method of retaining more audits online, while each individual audit file is relatively small.
AP-ADVICE-SAFEGARD-06 Use the method that best meets the requirements stated in the Corporate Security Policy.
3P-SAFEGARD-AUDIT-01 Use a third party product to produce Safeguard audit reports.
How Long Should Safeguard Audit Trails Be Saved
The Corporate Security Policy should mandate how long Safeguard audit trails must be kept online, how often they should be backed up to tape, and how long the archived files must be saved. This may depend on Industry Standards created by such agencies as the Securities and Exchange Commission or the Federal Banking System.
Configuring How the Safeguard Subsystem Writes Its Audits
Two AUDIT SERVICE attributes determine the manner in which audit records are written to disk. These are:
WRITE-THROUGH CACHE
EOF REFRESH
WRITE-THROUGH CACHE
The WRITE-THROUGH CACHE attribute determines whether or not audit records can be retained in memory or are written immediately to disk.
If WRITE-THROUGH CACHE is ON, after each audit record is written to memory, it is immediately written to disk.
If WRITE-THROUGH CACHE is OFF, audit records written to memory may be cached and not written to disk immediately.
RISK If OFF, a CPU crash will lose audit.
BP-SAFEGARD-CONFIG-05 The default and best practice value is WRITE-THROUGH CACHE OFF for performance reasons.
EOF REFRESH
The EOF REFRESH attribute determines whether or not the End Of File (EOF) marker will be updated after each audit record is written, even if the record is retained in memory.
If EOF REFRESH is OFF, the EOF will not be updated until the record is actually written to disk.
If EOF REFRESH is ON, the EOF will be updated.
If WRITE-THROUGH CACHE is ON, EOF REFRESH is automatically set ON.
But, if WRITE-THROUGH CACHE is then turned off,
EOF REFRESH remains ON.
BP-SAFEGARD-CONFIG-06 The default and best practice value is EOF REFRESH OFF.
Configuring AUDIT SERVICE RECOVERY Mode
The AUDIT SERVICE RECOVERY attribute determines how Safeguard software will behave if the current audit pool is either unassigned or becomes unavailable for any reason. Note that Safeguard software will always attempt to use the next audit pool if one is configured. Only if the next audit pool is also undefined or unavailable will Safeguard software go into the specified RECOVERY Mode when the current audit pool is unavailable.
There are three RECOVERY modes:
RECYCLE
SUSPEND AUDIT
DENY GRANTS
RECYCLE
When RECYCLE is selected, the oldest unreleased audit file will be reused. The file will be purged and a new file with the next sequence number created. For example, if the Audit Pool is configured to have a maximum of 10 files, when the 10 th file is full, Safeguard software will delete A0000001 and open a new file named A0000011.
If a disk fails, Safeguard must suspend auditing, because it can't create a new audit file.
RECYCLE does not apply to the audit pool $SYSTEM.SAFE whether it is the primary audit pool or the 'fallback' audit pool.
BP-SAFEGARD-CONFIG-07 RECYCLE is the recommended RECOVERY setting.
If RECOVERY mode is RECYCLE and the Corporate Security Policy and Standards require that Safeguard software audits be retained online for a specific time period, steps must be taken to prevent the loss of data due to Safeguard purging old audit files:
The Audit Trail must be large enough to retain the required amount of data.
The individual Audit Pools may require more and/or larger files.
AP-ADVICE-SAFEGARD-07 If RECOVERY mode is RECYCLE and the Corporate Security Policy and Standards require that Safeguard software audits be retained online for a specific time period, it is highly recommended that at least one secondary Audit Pool be configured and set as the NEXT AUDIT POOL. This will prevent the loss of data due to Safeguard software purging old audit files.
SUSPEND AUDIT
Safeguard software suspends auditing as long as the current audit pool is unavailable. This value guarantees that processing will continue even when Safeguard software cannot write its audits.
RISK During the time the audit is suspended , there will be no audit trail to provide accountability in case of a security breach.
DENY GRANTS
If the current audit pool becomes unavailable, and RECOVERY is configured to DENY GRANTS, Safeguard software will deny any authorization (object access attempts) and any authentication (logon) requests that require auditing. In this case:
RISK Only successful access attempts by members of the Security Groups will be granted.
RISK What auditing does occur will be redirected to $SYSTEM.SAFE. If there is no available space on $SYSTEM, no activity that requires auditing will be allowed. It will not even be possible to switch to another Audit Pool.
AP-ADVICE-SAFEGARD-08 If AUDIT SERVICE is configured to DENY GRANTS, make sure that $SYSTEM always has enough space for 'fallback' auditing or risk disruption of service.
AP-ADVICE-SAFEGARD-09 If AUDIT SERVICE is configured to DENY GRANTS, it is especially important to configure at least one secondary Audit Pool or risk disruption of service.
| Note | If the RECOVERY setting is DENY GRANTS and Safeguard software is included with system generation then, before shutting down the system, the current Audit Pool must be moved to a disk that is connected to the same CPU as $SYSTEM. |
Otherwise , auditing will be suspended during the cold load and Safeguard software will DENY access attempts that require audits. Once the Cold Load is complete, Safeguard software should be reconfigured to use the normal audit pool.
Managing Multiple Audit Pools
It is possible to have multiple audit pools on different volumes and subvolumes, but only one can be current at a time. When there are multiple audit pools:
Define which audit pool is to be used as the current audit pool; that is, which audit pool is to receive audit records.
Define the next audit pool to be used when the current audit pool is filled. Because an audit pool can contain several audit files, a system may have several different volumes and subvolumes containing multiple audit files.
Within an audit pool, when the current audit file is filled, Safeguard software automatically switches to the next available file in that audit pool. Alternatively, users can monitor usage of the audit files and manually switch to the next file or switch to another audit pool, as necessary.
As long as unused or released audit files remain available in the current audit pool, there is no danger of audit data being lost; even that danger is minimized if the NEXT AUDIT POOL has been specified. Therefore, part of the task of monitoring the audit service activity is to release (allow the purging of ) audit files that are no longer needed so that Safeguard software can reuse them.
| Note | The Safeguard subsystem writes a message to the system console each time it switches from one audit file to another. These messages can be used to determine when to extract data from a used audit file before it is recycled. |
SECURITY-GROUPs
The Safeguard SECURITY GROUPS make it possible to delegate to specific users the authority to execute certain restricted Safeguard commands. The SECURITY GROUPS do not exist until they are added .
The restricted commands are shown in the tables below.
RISK Until the SECURITY-GROUPS are added, the restricted Safeguard commands can be executed by all SUPER group members. Once the SECURITY GROUPS are created, only those users with EXECUTE authority on each SECURITY-GROUP's ACL (and SUPER.SUPER if configured UNDENIABLE) can use the commands restricted to that the group.
There are two valid SECURITY-GROUPS:
SECURITY-ADMINISTRATOR GROUP
SYSTEM-OPERATOR GROUP
Safeguard software does not treat SECURITY-GROUPS as objects. They are not affected by the Safeguard Warning Mode.
SECURITY-ADMINISTRATOR GROUP
Members of this group can manage (configure) all aspects of Safeguard and Safeguard auditing except releasing and 'rolling' Safeguard audit files.
BP-SAFEGARD-SECADMIN-01 The SECURITY-ADMINISTRATOR GROUP should be defined.
BP-SAFEGARD-SECADMIN-02 The User Record for the Security Admin userid itself, should be owned by SUPER.SUPER, so that SUPER.SUPER can restore access to the Security Admin userid if something goes wrong. For example, if the Security Admin userid is frozen or its password expires .
| Command | Without Sec Groups | SEC-ADMIN | SYS-OPER |
|---|---|---|---|
| ADD AUDIT POOL | SUPER group | Yes | Yes |
| ALTER AUDIT POOL | SUPER group | Yes | Yes |
| ALTER AUDIT SERVICE | SUPER group | Yes | No |
| DELETE AUDIT POOL | SUPER group | Yes | Yes |
| SELECT | SUPER group | Yes | Yes |
| ADD TERMINAL | SUPER group | Yes | No |
| ALTER TERMINAL | SUPER group | Yes | No |
| DELETE TERMINAL | SUPER group | Yes | No |
| FREEZE TERMINAL | SUPER group | Yes | Yes |
| THAW TERMINAL | SUPER group | Yes | Yes |
| ADD EVENT-EXIT-PROCESS | SUPER group | Yes | No |
| ALTER EVENT-EXIT-PROCESS | SUPER group | Yes | No |
| DELETE EVENT-EXIT-PROCESS | SUPER group | Yes | No |
| ALTER SAFEGUARD | SUPER group | Yes | No |
| STOP SAFEGUARD | SUPER group | Yes | No |
SYSTEM-OPERATOR GROUP
Members of this group can only FREEZE and THAW Safeguard-controlled terminals and manage the Safeguard audit trails.
BP-SAFEGARD-SYSOPR-01 The SYSTEM-OPERATOR GROUP should be defined.
BP-SAFEGARD-SYSOPR-02 The User Record for the System Operator should be owned by the Security Administrator user.
The SECURITY-GROUP Definition Records
Only a member of the local SUPER group can ADD Security-Group Definition Records. Once the groups have been created, each group definition record determines who is allowed to ALTER or PURGE it. Please refer to Managing Userids with the Safeguard Subsystem in Part Three.
The Security-Group Record attributes are:
Owner
ACL
Status
Audit Configuration
Security-Group Ownership
SECURITY-GROUP Protection Records respect the standard Primary and Secondary ownership privileges and processing.
In addition to the Primary Owner, the Primary Owner's group manager, and local SUPER.SUPER, any userid with OWNER authority in the SECURITY-GROUP Definition Record can also modify the Record.
Security-Group Access Control List
The following access authorities can be granted to users and user groups in a SECURITY-GROUP:
| EXECUTE | EXECUTE the appropriate restricted Safeguard commands |
| OWNER | ALTER or DELETE the Security-Group Record itself |
STATUS
The STATUS is either FROZEN or THAWED. If a SECURITY-GROUP Record is frozen, the authorities granted to userids listed on a security group ACL are temporarily suspended.
While the SECURITY-GROUP is frozen, only the primary owner, the primary owner's group manager, and local SUPER.SUPER can execute the commands restricted to that SECURITY-GROUP.
BP-SAFEGARD-SECADMIN-03 STATUS = THAWED
BP-SAFEGARD-SYSOPR-03 STATUS = THAWED
Security-Group Audit Attributes
SECURITY-GROUP audit attributes follow the same standards as other Protection Record audit attributes. The SECURITY-GROUP audit attributes are:
AUDIT-ACCESS-PASS
AUDIT-ACCESS-FAIL
AUDIT-MANAGE-PASS
AUDIT-MANAGE-FAIL
BP-SAFEGARD-SECADMIN-04 AUDIT- ACCESS-PASS = ALL
BP-SAFEGARD-SECADMIN-05 AUDIT- ACCESS-FAIL= ALL
BP-SAFEGARD-SECADMIN-06 AUDIT- MANAGE-PASS = ALL
BP-SAFEGARD-SECADMIN-07 AUDIT- MANAGE-FAIL= ALL
BP-SAFEGARD-SYSOPR-04 AUDIT- ACCESS-PASS = ALL
BP-SAFEGARD-SYSOPR-05 AUDIT- ACCESS-FAIL= ALL
BP-SAFEGARD-SYSOPR-06 AUDIT- MANAGE-PASS = ALL
BP-SAFEGARD-SYSOPR-07 AUDIT- MANAGE-FAIL= ALL
LAST-MODIFIED OWNER STATUS SECURITY-ADMINISTRATOR 7JAN03, 11:12 255,255 THAWED 222,233 E, O 222,250 E, O 253,001 E, O AUDIT-ACCESS-PASS = ALL AUDIT-MANAGE-PASS = ALL AUDIT-ACCESS-FAIL = ALL AUDIT-MANAGE-FAIL = ALL
Safeguard-Controlled Terminals
Safeguard software can be configured to take over control of the logon dialog at specific terminals. Some or all of the terminals on the system can be controlled by Safeguard. They are put under Safeguard software control by creating a Terminal Definition Record or dynamic TCP/IP ports configured to start LOGON.
Terminal Definition Records differ from Safeguard Object Protection Records in that there is no ACL portion. To control access to a Safeguard terminal, create a DEVICE (or SUBDEVICE) Protection Record based on the terminal's device name. See Device Security in Part Five.
The Terminal Definition Record also allows specification of a particular command interpreter to be started automatically at the terminal after user authentication.
| Note | Safeguard software can start a specific command interpreter only at a Safeguard terminal, that is, one put under Safeguard control with a Terminal Definition Record or LOGON program. Though the CI can be specified in a User Record and in a Safeguard Globals, it is enforced only at terminals controlled by Safeguard software. |
Safeguard-controlled terminals can also be configured for exclusive access, which ensures that any user who is logged on to a Safeguard terminal has exclusive access to the terminal until the user logs off. This feature is configured with the TERMINAL-EXCLUSIVE-ACCESS parameter.
Please see LOGON in Part Four for a detailed discussion of Safeguard-controlled terminals.
Who Can Add or Manage Safeguard-Controlled Terminals
If the SECURITY-ADMINISTRATOR group has been defined on the system, only SECURITY-ADMINISTRATOR GROUP members (and SUPER.SUPER if configured UNDENIABLE) can access terminal commands, other than INFO, which any user can execute.
RISK If the SECURITY-ADMINISTRATOR has not been defined on the system, any SUPER group member can execute the terminal commands.
Security Event-Exit Process (SEEP)
A SEEP is a process that participates in security policy enforcement. Depending on how the event-exit process is configured, Safeguard software passes it requests for Authorization Events, Authentication Events, and Password Change Events. The SEEP rules on the request and returns the ruling to Safeguard software for interpreta-tion and enforcement. The SEEP commands allow a security administrator to configure and manage the security event exit process.
RISK A poorly written SEEP can prevent Safeguard software from functioning correctly.
AP-ADVICE-SAFEGARD-10 SEEPs should only be created by extremely knowledgeable programmers.
3P-OBJSEC-SEEP-01 Use a third party Safeguard SEEP product to enhance Safeguard capabilities for object security.
3P-PASSWORD-SEEP-01 Use a third party Safeguard SEEP product to enhance Safeguard capabilities of password quality.
The SEEP Configuration Record
SEEP Configuration Records have the following parameters:
EVENT-EXIT-PROCESS (Name)
ENABLED
RESPONSE-TIMEOUT
ENABLE-AUTHENTICATION-EVENT
ENABLE-AUTHORIZATION-EVENT
ENABLE-PASSWORD-EVENT
PROG
PNAME
LIB
CPU
SWAP
PRI
PARAM-TEXT
Safeguard software does not treat SEEP Configuration Records as objects. They are not affected by the Safeguard Warning Mode.
The EVENT-EXIT-PROCESS
The EVENT-EXIT-PROCESS parameter determines the name of the SEEP Configuration Record.
ENABLED
The ENABLED parameter determines whether or not the SEEP is ruling on security events relayed from Safeguard software:
If ENABLED is ON, Safeguard software will start the process and send designated SEEP messages to the process.
If ENABLED is OFF, Safeguard software will not start the designated SEEP and will not send it any messages.
The default value is OFF. If this attribute is omitted, it is set to the default.
RESPONSE-TIMEOUT
The RESPONSE-TIMEOUT parameter determines the time, in seconds, which Safeguard software will wait for the SEEP to respond to an event.
The Safeguard's Subsystem response to a TIMEOUT depends on the type of SEEP:
If a Password-Quality SEEP times out and the user attempting the access is NOT a local member of the SUPER group, Safeguard software denies the password change request.
If an Authorization SEEP times out Safeguard software denies the access request.
If an Authentication SEEP times out for any user, Safeguard software denies the authentication request.
The default value is five seconds. If this attribute is omitted, it is set to the default.
ENABLE-AUTHENTICATION-EVENT
The ENABLE-AUTHENTICATION-EVENT determines whether or not authentication events will be sent to the SEEP:
If ENABLE-AUTHENTICATION-EVENT is ON, authentication events will be sent to the SEEP when it is enabled.
If ENABLE-AUTHENTICATION-EVENT is OFF, authentication events will not be sent to the SEEP.
The default value is OFF. If this attribute is omitted, it is set to the default.
ENABLE-AUTHORIZATION-EVENT
The ENABLE-AUTHORIZATION-EVENT determines whether or not authorization events will be sent to the SEEP.
If ENABLE-AUTHORIZATION-EVENT is ON, authorization events will be sent to the SEEP.
If ENABLE-AUTHORIZATION-EVENT is OFF, authorization events will not be sent to the SEEP.
The default value is OFF. If this attribute is omitted, it is set to the default.
ENABLE-PASSWORD-EVENT
The ENABLE-PASSWORD-EVENT determines whether or not password change events will be sent to the SEEP.
The PASSWORD SEEP behaves differently, depending on whether or not the AUTHENTICATION SEEP is also enabled:
If both the PASSWORD and AUTHENTICATION SEEPs are enabled, password changes that occur during login on are not sent to the Password SEEP, only password changes from the PASSWORD program and from the Safeguard ADD USER, ALTER USER, ADD ALIAS, and ALTER ALIAS commands will be sent to the Password SEEP
If the PASSWORD SEEP is enabled but the AUTHENTICATION SEEP is disabled, all password change events, included those that occur at login, are sent to the PASSWORD-SEEP for evaluation.
If ENABLE-PASSWORD-EVENT is OFF, password events will not be sent to the SEEP.
The default value is OFF. If this attribute is omitted, it is set to the default.
PROG
The PROG parameter specifies the object file Safeguard software will start when the SEEP is enabled. The object file must be a local file.
If no object file is entered, no program will be started. There is no default value.
LIB
The LIB parameter defines the library file, if any, is to be used with the SEEP.
If no library is specified, no library file will be used.
CPU
The CPU parameter determines the CPU in which the SEEP will be run. The valid entries are the word "any" or a two-digit number representing the CPU desired. If the value is ANY, any available CPU will be used.
If no CPU is specified, any available CPU will be used.
PNAME
The PNAME parameter determines the process name that will be assigned to the SEEP.
If no PNAME is specified, Safeguard software will generate a process name when it starts the SEEP.
RISK The PNAME should be unique. If a process of the same name already exists, Safeguard software will stop it before starting the SEEP.
SWAP
The SWAP parameter determines the location of the SEEP's swap space. The value must be a valid volume name. The subvolume and file names are optional.
The NonStop S series systems, the swap space can be controlled via the NSKCOM program.
PRI
The PRI parameter determines the priority at which the SEEP runs.
The default value is 155. If no PRI is entered, Safeguard software starts the SEEP at the default priority.
PARAM-TEXT
The PARAM-TEXT determines the data (if any) to be supplied as the startup message for the SEEP.
The PARAM-TEXT must be the final attribute in the command string.
If no PARAM-TEXT is entered, no startup text is used.
Who Can Manage SEEPs
SEEPs are managed with the EVENT-EXIT-PROCESS commands:
INFO
ADD
ALTER
DELETE
The INFO command can be executed by any user.
The ADD, ALTER, and DELETE commands can only be executed by members of the SECURITY-ADMINISTRATOR Security Group (and SUPER.SUPER if configured UNDENIABLE), if defined on the system.
If the SECURITY-ADMINISTRATOR Security Group is not defined, any SUPER group member can use these commands.
AP-ADVICE-SEEP-01 Only select users should be allowed to ADD, ALTER or DELETE SEEPs.
Safeguard Warning Mode
Warning Mode is intended for use as a tool for testing new Safeguard Protection Records as they are put into use on the system. When in Warning Mode, Safeguard software allows access to any object that has a Protection Record, even in those instances in which the ACL would deny the attempted access if it was in production. Safeguard audits any access attempt that would normally have been denied. Warning Mode makes it possible to test the effectiveness and accuracy of the new Protection Records. Once the Protection Records are implemented satisfactorily, change WARNING MODE to OFF to disable Warning Mode and enforce all Safeguard rules.
It is important to note the following facts about Warning Mode:
RISK Warning Mode is system-wide, the entire node is vulnerable as long as WARNING-MODE is ON.
RISK When WARNING-MODE is ON, Safeguard software allows access to all objects.
Objects that are not protected by Safeguard software are unaffected in Warning Mode. For example, if a disk file does not have a Safeguard Protection Record and ACL-REQUIRED-DISKFILE is OFF , access to that disk file will be unaffected by Warning Mode.
OBJECTTYPES, SECURITY GROUPS, Terminal Definition Records and SEEP Configuration Records are not affected by Warning Mode. Safeguard software does not treat them as objects.
If the Safeguard Global parameters ACL-REQUIRED-xxx (for example, DISKFILE, PROCESS or DEVICE) are configured ON, access is normally denied for any object that does not have a Protection Record. In Warning Mode, however, access to all such objects will be granted.
3P-OBJSEC-SEEP-02 Use a third party Safeguard SEEP product to enhance Safeguard capabilities for object security with the ability to perform rule-by-rule WARNING MODE
WARNING-MODE
The WARNING-MODE attribute determines whether or not the Safeguard subsystem is in Warning Mode:
If WARNING-MODE is ON, Warning Mode is enabled.
If WARNING-MODE is OFF Warning Mode is disabled.
The default value is OFF.
| Warning Mode Rulings on Object ACLs | ||||
|---|---|---|---|---|
| Safeguard ACL Ruling | Guardian Security | Access Result | Audit Generated | Outcome in Audit Record |
| Std Mode “ Grant | N/A | Yes | As specified | Granted |
| Std Mode - Fail | N/A | No | As specified | Denied |
| Warn Mode “ Grant | N/A [**] | Yes | As specified | Granted |
| Warn Mode - Fail | N/A [**] | Yes [*] | Always | Warning [*] |
| [**] Depends upon Fallback setting [*] Indicates that access result is due to Warning Mode evaluation of the ACL. | ||||
BP-SAFEGARD-GLOBAL-10 WARNING-MODE = OFF
WARNING-FALLBACK-SECURITY
Diskfiles and processes differ from other Safeguard objects in that they have Guardian security associated with them. The WARNING-FALLBACK-SECURITY is a Global attribute that determines how Safeguard software will rule on access attempts to these objects while it is in WARNING MODE.
WARNING-FALLBACK-SECURITY can be set to either GUARDIAN or GRANT:
If WARNING-FALLBACK-SECURITY is set to GUARDIAN, Safeguard software bypasses the Protection Record and bases it's ruling on the diskfile's Guardian Security String. This allows testing of the Safeguard software security settings while maintaining Guardian protection.
If WARNING-FALLBACK-SECURITY is set to GRANT, Safeguard bypasses both the Protection Record and the Guardian security string and grants the access that it would otherwise deny. This can be useful when the Guardian security has not been kept current with the security policy. This method of operation may also be useful in certain extreme emergency situations when routine security measures need to be suspended.
The default value is GUARDIAN.
RISK When WARNING-FALLBACK-SECURITY is set to GRANT, the system is vulnerable; all security is bypassed, granting users access that would otherwise be denied even by Guardian security.
BP-SAFEGARD-GLOBAL-11 WARNING-FALLBACK-SECURITY = GUARDIAN
Evaluating Disk File Access in Warning Mode
Diskfiles have Guardian Security Strings that affect the access granted while Safeguard software is in Warning Mode. In Warning Mode with the fallback option set to GUARDIAN, Safeguard software checks the Guardian disk file Security String before granting access:
If the Guardian security string grants the access, Safeguard allows the access and writes an audit record with the outcome WARNING.
If the security string does not grant the access, Safeguard denies the access. No audit record is written in this instance unless auditing is specified for the disk file.
| Warning Mode Rulings on Diskfile ACLs | ||||
|---|---|---|---|---|
| Safeguard ACL Ruling | Guardian Security | Access Result | Audit Record | Generated Outcome in Audit Record |
| Prod Mode “ Grant | N/A | Yes | As specified | Granted |
| Prod Mode - Fail | N/A | No | As specified | Denied |
| Prod Mode “ No Record | Use Guardian | Yes / No [#] | No | N/A |
| Grant | Grants | Yes | As specified | Granted |
| Grant | Denies | No | As specified | Granted |
| Deny | Grants | Yes [*] | Always | Warning [*] |
| Deny | Denies | No | As specified | Denied |
| No Record | Use Guardian | Yes / No [#] | No | N/A |
| Warning Mode With Grant Fall Back | ||||
| Grant | N/A | Yes | As specified | Granted |
| Deny | N/A | Yes [*] | Always | Warning [*] |
| NoRecord | Use Guardian | Yes / No [#] | No | N/A |
| [*] Indicates that access result is due to Warning Mode evaluation of the Protection Record. [#] Indicates that access resuld is determined by Guardian settings. | ||||
Evaluating Process Access in Warning Mode
Processes differ from other objects; they have default Guardian security rules and they have stop modes, which influence whether or not a process can be stopped by another process. There are three stop modes:
| Mode 0 | Process can be stopped by any other process. |
| Mode 1 | Process can only be stopped by:
Mode 1 is the default. |
| Mode 2 | Process cannot be stopped by any other process. |
| Note | If a process has stop mode 2 and the access attempt is granted, Safeguard software writes an audit record with the outcome of either WARNING or GRANTED, however, the process will not actually be stopped because the Guardian stop mode of 2 always takes precedence over the Safeguard ruling. The request will be pending until the process sets itself to a lower stop mode. |
| Warning Mode Rulings on Process and Subprocess ACLs | ||||
|---|---|---|---|---|
| Safeguard ACL Ruling | Guardian Security | Access Result | Audit Record | Generated Outcome in Audit Record |
| Std Mode “ Grant | Mode 0,1 | Yes | As specified As specified | Granted |
| Std Mode - Fail | Mode 0,1,2 | No | As specified | Denied |
| Std Mode “ No Record | Use Guardian | Yes / No | No | N/A |
| Warning Mode With Guardian Fall Back | ||||
| Grant | Mode 0,1 | Yes | As specified | Granted |
| Deny | Mode 0,1 | Yes [*] | Always [*] | Warning [*] |
| No Record | Use Guardian | Yes / No [#] | No | N/A |
| Warning Mode With Grant Fall Back | ||||
| Grant | Mode 0,1 | Yes | As specified | Granted |
| Deny | Mode 0,1 | Yes [*] | Always [*] Always [*] | Warning [*] |
| NoRecord | Use Guardian | Yes / No [#] | No | N/A |
| [*] Indicates that access result is due to Warning Mode evaluation of the ACL . [**] Attempts to stop a process at mode 2 do not produce a security violation message, but the process will not stop until the process sets itself to a lower stop mode. These requests are treated as pending and are audited as GRANTED or WARNING. [#] Indicates that the access result is determined by Guardian settings. | ||||
Safeguard Auditing
The ability to track security events on the system is one of the most important aspects of Access Control. On the HP NonStop server, Safeguard software audits information about a wide range of events in its audit files. The Safeguard audit files are collectively referred to as the Audit Trail.
Audit records are written to the Audit Trail as they are received (see the section: Configuring How Safeguard Writes Its Audits ) by the Safeguard Audit Service.
The Safeguard subsystem generates audit records for the events it controls. Some events are recorded regardless of Safeguard settings and other events will not be recorded unless specifically configured for auditing.
Configuring What Will Be Audited
Some Safeguard events are always audited. Most must be configured to enable auditing.
Safeguard Events That Are Always Audited
The following types of events are always audited, regardless of any Safeguard audit settings and regardless of whether or not the commands executed successfully:
Attempts to execute the Safeguard ALTER or STOP commands
Attempts to execute Safeguard AUDIT SERVICE commands other than INFO
Attempts to execute Safeguard TERMINAL commands other than the INFO
Attempts to execute EVENT-EXIT-PROCESS commands other than INFO
Safeguard Events That Must Be Configured For Auditing
The following types of events must have auditing specified to be recorded in the Safeguard audit trail:
Attempts to AUTHENTICATE users
Attempts to ACCESS objects
Attempts to CREATE or MANAGE Safeguard User/Alias Records
Attempts to CREATE or MANAGE Safeguard Protection Records
Attempts to CREATE or MANAGE Safeguard OBJECTTYPE Records
Automatic LOGOFFS that occur if a user logs on at an already logged on terminal
This section discusses how Safeguard auditing works and how to configure auditing in general. However, the recommended audit settings for each of the Object-classes is discussed in the sections devoted to the individual object types. For example, recommended audit settings for User Records are discussed in Part Three.
Configuring Global or System-wide Auditing
Normally, Safeguard software audits only those items that have auditing specified in their Protection Records. However, system-wide auditing can be configured so that auditing is performed even if it is not specified in individual Protection Records.
Auditing specified by Safeguard Global parameters supplements the settings in the individual Protection Records (provided that Safeguard software is configured to check the individual record). For example, if an individual record is set to audit local attempts and the Safeguard Global configuration is set to audit remote attempts, both local and remote attempts are audited.
To configure system-wide auditing of all system objects, in addition to the audit settings in the individual Protection Records, the Global parameters are:
AUDIT-CLIENT-SERVICE
AUDIT-OBJECT-ACCESS-PASS
AUDIT-OBJECT-ACCESS-FAIL
AUDIT-OBJECT-MANAGE-PASS
AUDIT-OBJECT-MANAGE-FAIL
AUDIT-CLIENT-SERVICE
HP privileged subsystems such as FUP and SCF are known as Clients. The AUDIT-CLIENT-SERVICE parameter determines whether or not Safeguard will accept event information from these clients and write the event records into the Safeguard audit trail on their behalf .
It is important to note the following facts about client auditing:
Audit records from clients are not standardized. Each client's audit records have different content and a different format.
Clients might not create the same audit records with the same content from release to release.
Auditing HP clients will consume considerable system resources and add a large number of records to the Safeguard audit files.
Some of the Safeguard Global audit parameters also affect client auditing. When AUDIT-CLIENT-SERVICE is ON:
The Global AUDIT-PROCESS-ACCESS-PASS or AUDIT-PROCESS- ACCESS-FAIL attribute values determine whether or not Safeguard software will write audit records not only for Safeguard-protected process objects but also for client operations that pertain to processes and subprocesses.
The Global AUDIT-DEVICE-ACCESS-PASS or AUDIT-DEVICE-ACCESS- FAIL attribute values determine whether or not Safeguard software will write audit records not only for Safeguard-protected device objects but also for client operations that pertain to devices and subdevices.
BP-SAFEGARD-GLOBAL-29 AUDIT-CLIENT-SERVICE = OFF if OSS is not in use on the system.
BP-SAFEGARD-GLOBAL-29 AUDIT-CLIENT-SERVICE = ON if OSS is in use on the system.
In order to enable Safeguard auditing of OSS activity, the AUDIT-CLIENT-SERVICE parameter must be ON.
RISK Turning AUDIT-CLIENT-SERVICE ON will generate a greatly increased number of auditable events and require more system resources to write the audit records.
AP-ADVICE-SAFEGARD-11 The system must have sufficient disk space to accommodate the increased size of the Safeguard audit trail(s)
AP-ADVICE-SAFEGARD-12 The system must have adequate system resources such as CPUs and memory to handle the increased amount of audit activity.
AUDIT-OBJECT-ACCESS{ -PASS -FAIL }
The AUDIT-OBJECT-ACCESS-PASS and AUDIT-OBJECT-ACCESS-FAIL parameters determine whether or not successful or unsuccessful attempts to access any object will be audited. The value can be ALL, NONE, LOCAL, or REMOTE.
This global attribute supplements the audit parameters for the individual objects. If the parameter in the individual object's Protection Record is LOCAL and the Global Attribute is REMOTE, then both LOCAL and REMOTE access attempts will be audited.
The default value for both PASS and FAIL is NONE.
BP-SAFEGARD-GLOBAL-30 AUDIT-OBJECT-ACCESS-PASS = NONE
BP-SAFEGARD-GLOBAL-31 AUDIT-OBJECT-ACCESS-FAIL = ALL
RISK Configuring Safeguard software to audit all system objects could cause system performance problems.
AP-ADVICE-SAFEGARD-13 The system must have adequate system resources such as CPUs and memory to handle the increased amount of audit activity.
AUDIT-OBJECT-MANAGE{ -PASS -FAIL }
The AUDIT-MANAGE-PASS or AUDIT-MANAGE-FAIL parameters determine whether or not successful or unsuccessful attempts to create or manage Protection Records for any object will be audited. The value can be ALL, NONE, LOCAL, or REMOTE.
This global attribute supplements the audit parameter for the individual objects. If the parameter in the individual object's Protection Record is LOCAL and the Global Attribute is REMOTE, then both LOCAL and REMOTE management attempts will be audited.
The default value for both PASS and FAIL is NONE.
BP-SAFEGARD-GLOBAL-32 AUDIT-OBJECT-MANAGE-PASS = ALL
BP-SAFEGARD-GLOBAL-33 AUDIT-OBJECT-MANAGE-FAIL = ALL
How the Safeguard Subsystem Determines What to Audit
Auditing is specified with either Global attributes or in Protection Records for individual objects. For example, auditing for an individual disk file is specified in the disk file's Protection Record, but auditing for all disk files on the system is specified with global attributes. Settings specified in individual Protection Records supercede those in the Safeguard Globals in some instances and supplement them in others:
If a Global AUDIT attribute is NONE but ALL in an individual Protection Record, then events for the object being protected will be audited.
If a Global AUDIT attribute is ALL but NONE in an individual Protection Record, then events for the object being protected will not be audited.
However, if a Global AUDIT attribute is REMOTE but LOCAL in an individual Protection Record, or vice versa, then both LOCAL and REMOTE events will be audited.
| Individual | Global | LOCAL | REMOTE | NONE |
|---|---|---|---|---|
| ALL | Audit ALL | Audit ALL | Audit ALL | Audit ALL |
| LOCAL | Audit LOCAL | Audit LOCAL | Audit ALL | Audit LOCAL |
| REMOTE | Audit REMOTE A | udit ALL | Audit REMOTE A | udit REMOTE |
| NONE | No audit | No audit | No audit | No Audit |
When an attempt is made to access a protected object, Safeguard software first checks the Protection Record for the target object to determine whether the user has the required authority to access the object.
If the user has the required permissions, the Safeguard subsystem allows the requested access and checks the value of the AUDIT-ACCESS-PASS attribute. If AUDIT-ACCESS-PASS is specified, the successful access is recorded in the current audit file.
If the user lacks the required permissions, the Safeguard subsystem issues a security violation and checks the value of the AUDIT-ACCESS-FAIL attribute. If AUDIT- ACCESS-FAIL is specified, the unsuccessful access is recorded in the current audit file.
Safeguard Globals and Configuration Recap
The following is a recap of the Safeguard configurations that have been discussed throughout this section and may be addressed in other sections of this book. In order to locate these important settings for the Safeguard environment, this table has been placed here for reference.
| Safeguard Global or Configuration | ||
|---|---|---|
| Safeguard Setting or Keyword | Value | |
| SAFEGARD-CONFIG-01 | SUPER.SUPER UNDENIABLE | YES |
| SAFEGARD-CONFIG-02 | OBJECTTYPE OBJECTTYPE Exists | YES |
| SAFEGARD-CONFIG-03 | OBJECTTYPE OBJECTTYPE owner should be SUPER.SUPER | YES |
| SAFEGARD-CONFIG-04 | Audit Trail not on $SYSTEM | <> $SYSTEM |
| SAFEGARD-CONFIG-05 | WRITE-THROUGH-CACHE | OFF |
| SAFEGARD-CONFIG-06 | EOF-REFRESH | OFF |
| SAFEGARD-CONFIG-07 | RECYCLE Audit Trails Mode | RECOVERY |
| SAFEGARD-GLOBAL-01 | AUTHENTICATE-MAXIMUM-ATTE MPTS | 3 |
| SAFEGARD-GLOBAL-02 | AUTHENTICATE-FAIL-TIMEOUT | 60 sec |
| SAFEGARD-GLOBAL-03 | AUTHENTICATE-FAIL-FREEZE | OFF |
| SAFEGARD-GLOBAL-04 | PASSWORD-REQUIRED | OFF |
| SAFEGARD-GLOBAL-05 | PASSWORD-HISTORY | 10 |
| SAFEGARD-GLOBAL-06 | PASSWORD-ENCRYPT | ON |
| SAFEGARD-GLOBAL-07 | PASSWORD-MINIMUM-LENGTH | 6 |
| SAFEGARD-GLOBAL-08 | PASSWORD-MAY-CHANGE | 7 |
| SAFEGARD-GLOBAL-09 | PASSWORD-EXPIRY-GRACE | 15 |
| SAFEGARD-GLOBAL-10 | WARNING-MODE | OFF |
| SAFEGARD-GLOBAL-11 | WARNING-FALLBACK-SECURITY | GUARDIAN |
| SAFEGARD-GLOBAL-12 | DIRECTION-DEVICE | SUBDEVICE-FIRST |
| SAFEGARD-GLOBAL-13 | CHECK-DEVICE | ON |
| SAFEGARD-GLOBAL-14 | COMBINATION-DEVICE | FIRST-ACL |
| SAFEGARD-GLOBAL-15 | CHECK-SUBDEVICE | ON |
| SAFEGARD-GLOBAL-16 | ACL-REQUIRED-DEVICE | OFF |
| SAFEGARD-GLOBAL-17 | DIRECTION-PROCESS | SUBPROCESS-FIRST |
| SAFEGARD-GLOBAL-18 | CHECK-PROCESS | ON |
| SAFEGARD-GLOBAL-19 | COMBINATION-PROCESS | FIRST-ACL |
| SAFEGARD-GLOBAL-20 | CHECK-SUBPROCESS | ON |
| SAFEGARD-GLOBAL-21 | ACL-REQUIRED-PROCESS | OFF |
| SAFEGARD-GLOBAL-22 | DIRECTION-DISKFILE | FILENAME-FIRST |
| SAFEGARD-GLOBAL-23 | CHECK-VOLUME | OFF |
| SAFEGARD-GLOBAL-24 | COMBINATION-DISKFILE | FIRST-ACL |
| SAFEGARD-GLOBAL-25 | CHECK-SUBVOLUME | ON |
| SAFEGARD-GLOBAL-26 | ACL-REQUIRED-DISKFILE | OFF |
| SAFEGARD-GLOBAL-27 | CHECK-FILENAME | ON |
| SAFEGARD-GLOBAL-28 | CLEARONPURGE-DISKFILE | OFF |
| SAFEGARD-GLOBAL-29 | AUDIT-CLIENT-SERVICE | OFF |
| SAFEGARD-GLOBAL-30 | AUDIT-OBJECT-ACCESS-PASS | NONE |
| SAFEGARD-GLOBAL-31 | AUDIT-OBJECT-ACCESS-FAIL | ALL |
| SAFEGARD-GLOBAL-32 | AUDIT-OBJECT-MANAGE-PASS | ALL |
| SAFEGARD-GLOBAL-33 | AUDIT-OBJECT-MANAGE-FAIL | ALL |
| SAFEGARD-GLOBAL-34 | AUDIT-AUTHENTICATE-PASS | ALL |
| SAFEGARD-GLOBAL-35 | AUDIT-AUTHENTICATE-FAIL | ALL |
| SAFEGARD-GLOBAL-36 | AUDIT-SUBJECT-MANAGE-PASS | ALL |
| SAFEGARD-GLOBAL-37 | AUDIT-SUBJECT-MANAGE-FAIL | ALL |
| SAFEGARD-GLOBAL-38 | AUDIT-DEVICE-ACCESS-PASS | NONE |
| SAFEGARD-GLOBAL-39 | AUDIT-DEVICE-ACCESS-FAIL | ALL |
| SAFEGARD-GLOBAL-40 | AUDIT-DEVICE-MANAGE-PASS | ALL |
| SAFEGARD-GLOBAL-41 | AUDIT-DEVICE-MANAGE-FAIL | ALL |
| SAFEGARD-GLOBAL-42 | AUDIT-PROCESS-ACCESS-PASS | NONE |
| SAFEGARD-GLOBAL-43 | AUDIT-PROCESS-ACCESS-FAIL | ALL |
| SAFEGARD-GLOBAL-44 | AUDIT-PROCESS-MANAGE-PASS | ALL S |
| AFEGARD-GLOBAL-45 | AUDIT-PROCESS-MANAGE-FAIL | ALL |
| SAFEGARD-GLOBAL-46 | AUDIT-DISKFILE-ACCESS-PASS | NONE |
| SAFEGARD-GLOBAL-47 | AUDIT-DISKFILE-ACCESS-FAIL | ALL |
| SAFEGARD-GLOBAL-48 | AUDIT-DISKFILE-MANAGE-PASS | ALL |
| SAFEGARD-GLOBAL-49 | AUDIT-DISKFILE-MANAGE-FAIL | ALL |
| SAFEGARD-GLOBAL-50 | CMON | ON |
| SAFEGARD-GLOBAL-51 | CMONERROR | ACCEPT |
| SAFEGARD-GLOBAL-52 | CMONTIMEOUT | 30 SEC |
| SAFEGARD-GLOBAL-53 | BLINDLOGON | ON |
| SAFEGARD-GLOBAL-54 | NAMELOGON | ON |
| SAFEGARD-GLOBAL-55 | TERMINAL-EXCLUSIVE-ACCESS | OFF |
| SAFEGARD-GLOBAL-56 | CI-CPU | default |
| SAFEGARD-GLOBAL-57 | CI-LIB | default |
| SAFEGARD-GLOBAL-58 | CI-PROG (it will default to $SYSTEM.SYSTEM.TACL) | default |
| SAFEGARD-GLOBAL-59 | CI-SWAP | default |
| SAFEGARD-GLOBAL-60 | CI-PRI | 145 |
| SAFEGARD-GLOBAL-61 | CI-PARAM-TEXT | default |
