For at least 35 years, HP NonStop (previously known as Tandem) has been a widely used operating system (OS) to support critical services such as automated teller machines (ATMs), stock exchanges and the airline industry. An HP NonStop system is a fault-tolerant and highly scalable hardware platform used mainly to support and sustain very large volumes of transactions.
This article presents an overview of the key principles used to audit an HP NonStop system. It is intended to help auditors in the preparation of their audit work plan.
As with any OS, the HP NonStop OS has basic areas that any auditor would need to test during an IT infrastructure audit, such as:
- User and group management
- Access to data
- Log management and monitoring
- System configuration
- Patching
- Privileged functions
When testing HP NonStop, auditors will find familiar principles such as the use of passwords, access control lists, a need for securing privileged programs and functions, and log management. The way HP NonStop has implemented these functions is very specific and auditors need to familiarise themselves with how the system enforces security.
Security services within an HP NonStop server are provided by two environments: Guardian1 and Safeguard. Guardian is fully integrated with the HP NonStop OS, while Safeguard is optional software that requires separate installation. Guardian security is supplemented by Safeguard as the latter extends the OS’s security features by adding auditing and extended authentication and authorisation capabilities.2
Applications can be deployed in one or both of the two HP NonStop OS’s environments (see figure 1): Guardian and Open Systems Services (OSS).3 Some of the security features from Guardian and Safeguard apply to the OSS environment. Safeguard can be configured to let users log in to the OSS environment directly without going through Guardian authentication; Safeguard must be used to manage users and groups within the OSS.
User and Group Management
Each Guardian user has a unique username and user ID, which are formatted as follows:
- Username: group-name.member-name
- User ID: group-number,member-number(from 0 to 255)
The two parts (member and group) are combined together to identify a specific/unique user ID.
Groups are used to bundle user IDs into clusters of users with similar privilege levels. This simplifies access management and enables the use of access control lists (ACLs), which can be configured to grant or deny access to a specific group.
A particular difference between HP NonStop and other OSs is that a user ID can be a member of only one group. This creates situations where end users have to use several user IDs to undertake their work.
The following are special user IDs used across HP NonStop in the context of access management:
- Group manager with user ID n,255 (where n is an integer from 1 to 254 indicating the number of the group) has additional privileges over the group membership, such as the ability to add/remove users, and is considered a privileged user.
- User ID 255,n (where n is an integer from 1 to 254 indicating the user number in the group) is called the super group user and has special privileges, for instance, to administer volumes, diskfiles and peripheral devices.
- The group manager of the super group (i.e., 255,255) is called SUPER.SUPER. This is the most powerful user ID on the platform and is the equivalent to root or administrator for UNIX and Windows systems. SUPER.SUPER has unrestricted access to the entire HP NonStop environment; this ID can access files and processes, bring down devices and impersonate any user ID.4 SUPER.SUPER must be used only for emergency situations (and nonroutine operations). As part of day-to-day operations, this account should be frozen and its password placed under dual control (e.g., via a password administration tool).
- The NULL.NULL (0,0) user ID is active during the OS installation. Usually the NULL.NULL user ID is either frozen or removed as part of the system security configuration. The key security user IDs in HP NonStop include:
- Security administrator, e.g., 250,254
- System operator, e.g., 255,254
- Security OSS administrator (equivalent to root in UNIX)
Aliases
Aliases are one peculiarity of HP NonStop. They are secondary user IDs that inherit the full set of privileges from an underlying user ID. All accounts5 can have an alias and this is used to improve accountability for access when several individuals need to use a particular user ID. For example, the SYSTEM.OPERATOR can have several aliases assigned to named individuals and they can use their personal user ID to undertake configuration activities within the system.
To enforce accountability, the powerful generic account can be frozen (locked) with only aliases allowed to use its privileges in an accountable manner. Figure 2 illustrates how aliases work. When logging on using an alias, there is no need to type the group membership; by writing the alias, the system recognises the underlying user ID.
User Repository
Another characteristic of the user ID management in HP NonStop is that the length of the username is limited. Every user ID has an owner and when ownership is not clearly reflected on the system, organisations often maintain off-line user ID repositories. Auditors must review these to confirm whether they are up to date and include valid individuals responsible for each user ID.
File Structure and Guardian File Security
The file structure followed in an HP NonStop server is:
- $volume—Equivalent to the drive in Windows systems (C:\, D:\, etc.)
- Subvolume—Equivalent to a folder in Windows systems (Win, System, etc.)
- Diskfile—Equivalent to files (cmd.exe, root.sh, etc.)
- $VOLUME.SUBVOLUM.DISKFILE in a \NODE—An example of a file structure
Under Guardian, every file has an owner and a file security string:
- R—Read the file.
- W—Write to the file.
- E—Execute the file.
- P—Purge the file.
Each security string can be associated to a type of user, such as user (O/U),6 group (G/C),7 any level (A/N)8 and SUPER.SUPER only (-).
Figure 3 illustrates an example of diskfile permissions under Guardian.
NUNU in figure 3 means that any user on the local system or on the network can read and execute the file, but only the owner on the local system or on the network can write to or purge the file. If this field appears as ****, it means that there is a Safeguard protection record (ACL) for the diskfile, i.e., T9750G06.
Access Control Lists
Guardian provides basic diskfile-level security with no auditing capabilities. To enhance security, Safeguard9 must be deployed to protect object definitions (e.g., OBJECTTYPE), volumes and subvolumes via the use of ACLs and the definition of global configuration parameters.
Access to data and objects (e.g., volumes, devices, processes, terminals) is controlled using ACLs. These are used by the HP NonStop OS to determine whether a user ID can be granted access to a particular diskfile. The system checks whether the user ID or group has been included in the relevant ACL and then grants or denies access accordingly.
ACLs must be reviewed periodically, and auditors should test for orphan user IDs (belonging to individuals who have left the organisation) and confirm that the entries in the ACLs reflect the business requirements.
HP NonStop systems usually are interconnected to create a proprietary network. User IDs can be authorised to transcend the network and connect across different nodes that are members of the same network. When a user ID is granted network access, the following parameter is added to the user ID configuration: \*. This will also appear on the ACLs, confirming the type of access granted to those network users.
The access options available for ACLs are read, write, execute, purge, create, deny and own (i.e., R, W, E, P, C, D, O). The letters representing these privileges are in front of the user ID or group linked to the object (volume, subvolume, diskfile).
In figure 4, the owner of the ACL applied at the volume level is SUPER.SUPER. The SECURITY.OPERATOR (250,254) is allowed to read, write, execute, purge and create, including files in remote nodes. The SUPER group is allowed to read, write, execute, purge and create locally; and the SECURITY group is denied access to write, execute, purge or create, including files in remote nodes.
These ACLs are the backbone of the logical access model for the HP NonStop platform. Each object can have an allocated ACL, and user IDs can be added into groups to simplify access management.
Auditing Objects
ACLs can also include an auditing component; any attempt to manage (alter or delete) or access can be monitored. The parameters that can be used are AUDIT-ACCESS-[PASS/ FAIL] and AUDIT-MANAGE-[PASS/FAIL]. These two audit options are followed by the attribute to be audited:
- All (all attempts)
- None (no attempts)
- Local (only local attempts)
- Remote (only remote attempts)
Key Risk Areas
Like any other technology platform, HP NonStop systems bring risk. Organisations such as banks, government bodies and stock markets that rely on critical HP NonStop environments to achieve their business objectives require a secure deployment of the OS.
Auditors need to consider the key risks shown in figure 5 while auditing HP NonStop systems.
Testing for Access
Areas to consider include:
- ACL configuration—Each organisation has a different model for ACL configuration. The risk being addressed is unauthorised access, either by having a group that is too wide or by having more permissions than the minimal requirement for business needs. From a testing perspective, it is necessary to look at all ACLs and understand the effect of the access being granted.
A common approach found on HP NonStop deployments is to have one volume dedicated to the system subvolumes and a separate volume dedicated to the application-related subvolumes. On the system subvolumes, one expects to see ACLs granting access to the support/engineering group and the group dedicated to changes. For the application subvolumes, one expects to see specific groups being granted access to support individual applications.
As part of the testing strategy, auditors should confirm whether a risk-based approach has been taken to define the access model and whether it considers access to system files, customer applications and customer data. Engineering teams should not have access to customer applications or customer data; this should be limited to the application support teams. Similarly, application support teams should not have access to customer data files.
Although difficult to implement, the SUPER.SUPER user ID should be specifically denied access to customer files; it can inherit access if this is not done.10 From an audit perspective, denied attempts to manage and access any diskfile should be recorded as well as granted access to manage diskfiles with customer data.
To reduce the risk of unauthorised access, all ACLs should be reviewed at risk-based intervals and entries should be validated or certified by data or application owners. Special attention should be given to user IDs with aliases. It should be clear for the data/application owner that when the underlying user ID is authorised, so are all the aliases. - Password management—As with any other OS, password management is a key control for reducing the risk of unauthorised access. When testing the password controls, auditors can look for the following key parameters defined in the Safeguard global configuration settings:
- PASSWORD-REQUIRED—All user IDs are required to provide a password.
- PASSWORD-ENCRYPT—Passwords are stored in encrypted form.
- PASSWORD-MINIMUM-LENGTH—Passwords must have a minimum length.
- NAMELOGON—Users cannot use their user number (instead of the numeric user ID, they need to use their username). This increases the complexity of guessing the user ID (numeric IDs have a limited and known set of combinations, while alphanumeric user IDs are more complex).
- PASSWORD-MAY-CHANGE and PASSWORD-MUST CHANGE—These two parameters set the minimum and maximum period of time allowed for password changes.
- BLINDLOGON—This parameter is used to hide the password echo on screen, protecting against ‘shoulder surfing’.
Additional password complexity requirements can be implemented using third-party software (e.g., Xypro). - User management—This is a critical function and it is possible to implement segregation of duties for the different tasks required. In general, the life cycle for user management includes creating a user ID, assigning privileges, setting up the password and activating the account.
Each task can be assigned to a separate team, granting access to the user ID configuration from different perspectives. For example, one group could be able to create user IDs, another could be able to change them and a third could be able to activate them.
As mentioned earlier, it is likely that the same individual would have several user IDs where each is a member of a different group. Auditors must test that ownership and accountability for each user ID and alias is clear.
Conclusion
A brief overview of the HP NonStop platform security—with particular focus on access controls—has been covered in this article. The reader should note that there are many other critical components, environments and security configuration settings to consider while auditing HP NonStop. Auditors need to focus, first, on gaining a sufficient understanding of this complex underlying technology prior to undertaking a security review of the controls.
Endnotes
1 Guardian is an environment made of an application program interface (API), tools and utilities in which an HP NonStop server runs. Application programs make calls to the HP NonStop OS’s functions (e.g., access to a disk) via the Guardian environment.
2 Hewlett-Packard Development Company LP, Security Management Guide, HP NonStop technical library, 2011, http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02131793/c02131793.pdf
3 OSS is a UNIX-like environment based on the X/Open Common Application Environment (CAE) specification that conforms to the Portable Operating System Interface (POSIX) 1 and 2 standards.
4 Unless, via Safeguard, the SUPER.SUPER has been explicitly denied to be the owner of a user ID.
5 The SUPER.SUPER ID should not have aliases.
6 O, the owner of the file on the local HP NonStop system, can perform the assigned operations (RWEP). U, the owner of the file on the local or remote HP NonStop server, can perform the assigned operations (RWEP).
7 G, members of the owner’s group on the local system, can perform the assigned operations (RWEP). C, members of the owner’s group on the local or remote HP NonStop server, can perform the assigned operations (RWEP).
8 A, any user on the local HP NonStop system, can perform the assigned operations (RWEP). N, any user on the local or remote HP NonStop system, can perform the assigned operations (RWEP).
9 User interaction with Safeguard is via a command interpreter called Safecom, from which a user can issue commands.
10 Look for ‘undeniable’ in the system configuration files (e.g., CONFTEXT); if such an entry exists, the SUPER. SUPER has unrestricted access to files because Safeguard ignores explicit denials set for it.
David Ramirez, CISA, CISM, CISSP, BS 7799 LA, MCSE, QSA, is an IT audit director for Barclays Internal Audit. Ramirez has more than 16 years of experience. He has published a number of articles and white papers on IT risk, and his book on Internet Protocol Television (IPTV) security was published by Wiley in 2008.
Nikos Zarras, CISA, MBCS, is an associate vice president working for State Street in the UK. Zarras has more than eight years of experience in computer auditing, risk and security in the finance, retail and public services industries. His main interest lies with the technology controls across mainframe and midrange platforms.