Privileged IDs

Certain userids have special privileges which make them more powerful and, therefore, potentially more dangerous:

IDs with inherent Guardian privileges

Application Owner Userids

Job Function Userids

On Secure systems, use of these Privileged IDs by individual users should be tightly controlled.

Userids With Inherent Guardian privileges

The HP NonStop server Guardian operating system grants special privileges to several userids. These privileges will be granted the moment the userids are created. The privileges can only be limited by implementing Safeguard software. These IDs are:

NULL.NULL (0,0)

NULL.FTP (0,15)

anonymous (0,15)

FTP (0,15)

Group Manager IDs (*,255)

SUPER group IDs (255,*)

SUPER.SUPER (255,255)

NULL.NULL

The NULL.NULL's user number is 0,0. This userid is provided on the HP SUT tapes as an owner of a logged off TACL process.

RISK NULL.NULL can stop any process with PAID of 0,0, i.e. a logged off TACL.

If NULL.NULL cannot be deleted, mitigate the risk of having it on the system by taking the following steps:

BP-USER-NULLNULL-01 Rename the 0,0 userid to something other than NULL.NULL.

BP-USER-NULLNULL-02 Expire or FREEZE the 0,0 userid so it can't be used to logon to the system.

Group Manager IDs

The Group Manager is the 255 member of any group. Some of the risks associated with Group Manager IDs are:

RISK Group Managers can ADD, ALTER and DELETE userids in their own group if Safeguard software it not present.

RISK Group Managers can 'log down' to the userid of any member of the same group without a password unless prevented by Safeguard software.

RISK Group Managers can PROGID any program owned by a group member.

RISK In Safeguard, the group manager of the Primary Owner of any object's Protection Record can also modify any Safeguard Protection Records owned by members of the same group.

It is not unusual for a Group Manager userid to be either an Application Owner or Job Function ID. Please refer to the section on Application Owner IDs later in this chapter.

SUPER Group IDs

A SUPER group member is any userid in group number 255. Some of the risks associated with SUPER Group member userids are:

RISK SUPER Group members can set and reset the system time.

RISK SUPER Group members can typically manage all jobs in the SPOOLER, regardless of who owns them.

RISK SUPER Group members can typically manage all jobs in PERUSE, regardless of who owns them.

RISK SUPER Group members can perform all commands within SCF.

SUPER.SUPER

The SUPER group number is 255. The Group Manager's member number is 255, therefore, 255,255 is commonly referred to as SUPER.SUPER or the SUPERID. When an HP NonStop server is shipped, the SUT tape assumes the existence of the SUPER.SUPER ID. If the ID doesn't exist when the tape is used, it is created.

The SUPER.SUPER userid is provided on the HP SUT tapes

RISK SUPER.SUPER can log on as any other user ID without a password unless explicitly denied in SAFEGUARD.

RISK SUPER.SUPER can ADD, ALTER or DELETE any userid in the Guardian and Safeguard environments if SUPER.SUPER is not configured DENIABLE.

RISK SUPER.SUPER can READ, WRITE, EXECUTE, or PURGE any file on the system.

RISK SUPER.SUPER can stop any process.

RISK SUPER.SUPER can debug any process.

RISK SUPER.SUPER can run any program or utility.

RISK SUPER.SUPER can bring up or take down any device.

RISK SUPER.SUPER can LICENSE any program.

RISK SUPER.SUPER can PROGID any program.

RISK SUPER.SUPER can manage all jobs in the Spooler, regardless of ownership.

RISK SUPER.SUPER can manage all jobs in the PERUSE, regardless of owner.

RISK The operating system runs as SUPER.SUPER.

RISK Safeguard, Expand and most other system processes run as SUPER.SUPER.

By default, the inherent abilities of SUPER.SUPER are local only. Privileges on one system do not extend to another system. A user logged on to a local system as the SUPER.SUPER is not automatically accorded SUPER.SUPER privileges on a remote system.

The user name SUPER.SUPER is not required. Some Corporate Security Policies and Standards mandate that the name be changed to a name not readily known to potential hackers. On a new system, the name should be changed:

After the Security Admin userid has been created

Before any other userids have been created in the SUPER Group

Before any major processes are started.

On an existing system, the change is more problematic because all SUPER group IDs must be deleted before the group name can be changed. This should only be undertaken after extensive thought and preparation.

Special Considerations for Reducing the Use of SUPER.SUPER

The SUPER.SUPER ID is used for system configuration and to resolve system emergencies. It is not intended for routine operational use. Without special mechanisms provided by Safeguard software, SUPER.SUPER has unlimited access to all resources on a local system.

Although SUPER.SUPER is not required for day-to-day operations, SUPER.SUPER might be required to:

LICENSE object files

PROGID object files to SUPER.SUPER

Manage userids if Safeguard software is not installed

Run BACKUP and RESTORE

Resolve certain emergencies

Perform System INSTALLs

LICENSE or PROGID Object Files

3P-ACCESS-USER-01 A third party access control product can be used to grant authorized users access to FUP running as SUPER.SUPER. The use of the

LICENSE and PROGID commands should be restricted for all but authorized users.

3P-OBJSEC-USER-01 A third party object security product can grant theLICENSE and PROGID authorities to other users on a file-by-file basis.

Please refer to the Gazette section on LICENSED Files and PROGID'd Files for detailed information on securing these files.

Manage Userids

If Safeguard is not used to manage userids, SUPER.SUPER is needed to:

ADD new user groups

ADD user IDs to administrative groups that do not have a group manager ID

DELETE user IDs from administrative groups that do not have a group manager ID.

RISK If Safeguard software is not installed, recovering the SUPER.SUPER userid if it is deleted from the system can be difficult. There are only two options:

If no CIIN file was specified when the system was generated, a system load can be performed from the System Console. The operator becomes SUPER.SUPER and can then ADD the SUPER.SUPER userid to the USERID file.

If a CIIN file was specified when the system was generated, a system load from a tape might need to be performed. The USERID file on the tape contains an entry for SUPER.SUPER.

BP-USER-POLICY-01 Use Safeguard software to manage userids.

Managing Processes

AP-PROCESS-SAFE-01 Use Safeguard software to selectively grant the ability to stop processes (both NAMED and UNNAMED) to an appropriate set of users.

3P-PROCESS-SPECIAL-01 Third party process control products provide the capability of delegating to the appropriate users, such as an operator, the ability to manage processes owned by other users, such as application Pathway servers. These products also provide auditing of the process management activities they control.

Resolve Emergencies

3P-ACCESS-USER-01 A third party access control product can be used to grant authorized users granular access to utilities running as SUPER.SUPER. These products also provide auditing of the activities they control.

BACKUP and RESTORE

Because only SUPER.SUPER has inherent READ access to every file on the system, BACKUP and RESTORE are usually run as SUPER.SUPER. There are three solutions to running BACKUP and RESTORE without users logging on as SUPER.SUPER. They are listed in order of preference:

1. Third party access control product:

   3P-ACCESS-BACKUP-01 Use a third party access control product to allow the users responsible for creating backups the ability to run BACKUP as SUPER.SUPER.

   3P-ACCESS-RESTORE-01 Use a third party access control product to allow the users responsible for restoring files the ability to run RESTORE as SUPER.SUPER.

2. PROGID'd BACKUP and RESTORE object files:

   Create copies of the BACKUP and RESTORE and PROGID these copies to SUPER.SUPER.

   RISK PROGID'd programs must be secured against unauthorized use.

   AP-ADVICE-BACKUP-01 The PROGID'd copies of BACKUP and RESTORE should not reside in $SYSTEM.SYSTEM, $SYSTEM.SYSnn or any subvolume in the PMSEARCHLIST that is shared by all users.

   AP-ADVICE-RESTORE-01 The PROGID'd copies of BACKUP and RESTORE should be secured so that only users authorized to create backup tapes can execute them.

3. Safeguard Protection Records that grant read access to every file:

   Create a Job Function ID, such as SUPER.BACKUP, that will be used to run the BACKUP and RESTORE programs. Grant this ID READ access to every file on the system via Safeguard software .

   RISK Maintenance of Safeguard Protection Records for every file on the system is impractical .

System Install

Normally SUPER.SUPER is required to perform a system installation or update. However, if the INSTALL program has PROGID set to the SUPER.SUPER, other users can run INSTALL.

Secure the PROGID'd INSTALL so only the appropriate SUPER Group members have EXECUTE authority. (Remember that, in this instance, file-sharing members of the SUPER Group also receive EXECUTE authority).

Application-Owner IDs

Application-Owner IDs provide the "place holder" ownership of all application objects on a system. Each application should be assigned the following four userids:

AP-USER-APPOWNER-01 An Object code owner

AP-USER-APPOWNER-02 A Source code owner

AP-USER-APPOWNER-03 A Database owner

AP-USER-APPOWNER-04 An Executing (Pathway) owner which runs the application and generates batch jobs.

This schema provides clear separation of ownership for the file-based entities as well as the running application processes that make up the on-line and batch. Under this configuration, control over each component of an application is divisible along the lines of those four userids, each restricted to the required privileges based on Least Privilege and Separation of Duties.

For example, the Executing ID WRITES to the database, but the database files are owned by the Database Owner, who alone can configure the database files. The Executing ID executes the object code but can't PURGE or ALTER it, and has no access to source code.

Some companies choose to have a single userid own the source code for all the applications.

RISK Having a single source code owner makes it more likely that the source code files for one application might be inadvertently accessed by developers for another application.

AP-ADVICE-APPOWNER-01 Use consistent naming conventions to make the separate source code files more obvious to the users and easier to secure.

Some companies choose to have a single userid own (configure) the databases for all applications.

RISK Having a single database owner makes it more likely that the databases for one application might be inadvertently accessed by another application.

AP-ADVICE-APPOWNER-02 Use consistent naming conventions to make the separate databases more obvious to the users and easier to secure.

All user access to the production data, the production Pathway, and the Production jobstreams must be limited in scope and audited .

Job-Function IDs

Access rights to system objects are allocated to the Job Function userids. Job Function userids are created for each functional area defined within the organization, and access for each Job Function userid is assigned to System and Application Owner objects based on their Job Function definition and specific needs. Some appropriate Job Functions might be:

AUDIT

CHANGE CONTROL

DEVELOPMENT (by application area)

FILE TRANSFER ANALYSTS

FILE TRANSFER OPERATORS

NETWORK/COMM SUPPORT

OPERATIONS MANAGEMENT

QUALITY ASSURANCE (by application area)

JOB SCHEDULING

SECURITY

SYSTEM MANAGEMENT

For example:

The Security Admin userid exists to own security tools and security objects such as USER Records and Safeguard Protection Records.

The RDF manager ID exists to own all the RDF programs, processes and databases.

The Change Control manager ID exists to transfer application code and configuration files from development to production.

The NonStop TMF manager ID exists to own all the TMF programs, processes and databases.

Securing Privileged Userids

AP-USER-PRIVLEGE-01 No users should be assigned a Privileged ID as a personal userid

RISK If users can log directly on as a shared Privileged ID, there is no accountability for any of their actions. The audit trails for Safeguard software and any third party Security products will show only that the activity was performed by a Privileged ID, not the user who is working as SUPER. SUPER.

AP-USER-PRIVLEGE-02 No user should be assigned NULL.NULL as a personal userid. NULL.NULL should not exist or be FROZEN.

AP-USER-PRIVLEGE-03 No users should be assigned a Group Manager ID as a personal userid.

AP-USER-PRIVLEGE-04 No users should be assigned an ID in the SUPER Group as a personal userid.

AP-USER-PRIVLEGE-05 No users should be assigned SUPER.SUPER as a personal userid.

AP-USER-PRIVLEGE-06 No users should be assigned an Application Owner ID as a personal userid.

AP-USER-PRIVLEGE-07 No users should be assigned a Job-Function ID as a personal userid.

AP-USER-PRIVLEGE-08 Privileged IDs should never be shared.

AP-USER-POLICY-01 Users should not be able to logon as any Privileged ID except for emergencies or pre-approved reasons.

AP-USER-PRIVLEGE-09 Privileged IDs should be FROZEN unless applications will not run with a FROZEN owner.

AP-USER-PRIVLEGE-10 All Privileged IDs should be treated as 'check out' or 'firecall' IDs.

AP-USER-PRIVLEGE-11 When the Privileged ID userid has been 'checked out,' the password should be set to expire after a short but reasonable time.

AP-USER-PRIVLEGE-12 When the Privileged ID userid has been 'checked in,' the password should be reset and locked up again.

AP-USER-POLICY-02 Privileged ID's passwords must expire and be changed at regular intervals.

AP-USER-POLICY-03 The only written copy of any Privileged ID's password must be kept under lock and key.

3P-CMON-PRIVLEGE-01 Use CMON to prevent users from directly logging onto the system as a Privileged ID.

3P-ACCESS-PRIVLEGE-01 Third party access-control software should be used to grant granular access to any Privileged ID for users who require these privileges in order to perform their jobs. These products provide command restrictions within utilities and programs as well as comprehensive auditing of the activities they mediate .

3P-PROCESS-PRIVLEGE-01 Third party process control software should be used to grant granular management of processes running as any Privileged ID for users who require these privileges in order to perform their jobs. These products provide comprehensive auditing of the activities they control.

BP-SAFEGARD-OBJTYPE-02 Safeguard OBJECTTYPE Records should be created to control the user management privileges of any Group Managers.

	Discovery Questions	Look here:
USER-POLICY-01	Is Safeguard software used to Manage userids?	Policy
USER-POLICY-02	Are procedures in place to authorize and document the use of all the Privileged IDs as "check out" or "firecall" IDs?	Policy
USER-POLICY-03	Are the Privileged IDs passwords changed at regular intervals?	Policy
USER-POLICY-04	Are the Privileged IDs passwords stored in a safe or other secure place?	Policy
CMON-PRIVILEGE-01	If users are allowed to logon as any Privileged ID, are 'stepped' logons enforced with CMON?	Policy
USER-PRIVLEGE-01	Are any Privileged IDs personal userids?	Policy USERS
USER-PRIVLEGE-02	If the 0,0 userid exists, is it called NULL.NULL?	USERS Safecom
USER-PRIVLEGE-03	Are any Group Manager ids used as personal userids?	USERS Safecom
USER-PRIVLEGE-04	Are any Super Group Manager ids used as personal userids?	USERS Safecom
USER-PRIVLEGE-05	Is SUPER.SUPER used as a personal userid?	USERS Safecom
USER-PRIVLEGE-06	Are any Application Group Owner ids used as personal userids?	USERS Safecom
USER-PRIVLEGE-07	Are any Job Function ids used as personal userids?	USERS Safecom
USER-PRIVLEGE-08	Are any of the Privileged IDs shared IDs?	USERS Safeguard
USER-PRIVLEGE-09	Are all the Privileged IDs on the system FROZEN?	USERS Safeguard
USER-PRIVLEGE-10	Are all the Privileged IDs 'checkout' IDs?	USERS Safeguard
USER-PRIVLEGE-11	Are all the Privileged ID's passwords set to expire after a short interval?	USERS Safeguard
USER-PRIVLEGE-12	Are all the Privileged ID's passwords reset after'checkin'?	USERS Safeguard