David Ramirez, CISA, CISM, CISSP, BS 7799 LA, MCSE, QSA and Nikos Zarras, CISA, MBCS
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:
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.
Each Guardian user has a unique username and user ID, which are formatted as follows:
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:
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.
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.
The file structure followed in an HP NonStop server is:
Under Guardian, every file has an owner and a file security string:
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.
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.
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:
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.
Areas to consider include:
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.
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.
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.
Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2013 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.