by Dave Teal, Security Solutions Architect, XYPRO Technology Corporation
The central nervous system of all BASE24 and BASE24-eps payment solutions running on the HPE NonStop is XPNET. XPNET is responsible for driving data communications lines, controlling stations, lines and processes defined to it, routing transaction messages, managing transaction message queues, communicating with other XPNET processes, enabling continuous processing, running system traces, monitoring the network, generating statistics, interfacing to the operating system, and generating and writing event messages to EMS.
The command interface to XPNET is Network Control Point Communications (NCPCOM). NCPCOM is used to configure, operate, and monitor a XPNET environment, like PATHCOM is used to configure, operate, and monitor a Pathway environment.
Unlike Pathway, XPNET has a security component that provides for optional user authentication and command-level access control and auditing. NCPCOM command access security is defined in the Network Control Security Profile File (NCSP) and the Network Control Security Specification (NCSS) files. The level of command access control can be defined to a given command (e.g. ALTER, CONTROL, INFO, START, STOP, etc.) for a given object type (e.g. DEVICE, LINE, STATION, PROCESS, etc.), but not for a given object (e.g. P1A^ATM1, P1B^HOST1, etc.).
For example, a user might have access to the STOP command for STATION. Stopping a station has the effect of preventing communications from/to the endpoint. This means from NCPCOM, the user could successfully execute STOP STATION <any station> and STOP STATION *. The user whose job-role includes stopping ATM stations, can also stop stations configured for POS devices, backend hosts, and card networks, effectively closing the doors to everything (financial transactions) coming into or exiting one or more XPNET nodes.
XYGATE Access Control (XAC)
XAC is a privileged access management solution from XYPRO for the NonStop that facilitates:
A role-based access control environment is established by requiring all users to logon with a personal user ID. There are no shared user IDs and no aliases. Routine privileged access is provided only by XAC. Users have access to XAC commands only if they are defined to XAC role-based ACL groups. Using XAC, commands are configured that run a given shell or utility program (e.g. TACL, FUP, SCF, etc.) as any user ID or alias. One of XAC’s essential features is to allow people who have a job-role that requires them to be a privileged user for a given task to do so without knowing the privileged user’s password. In other words, they are required to use XAC to become that privileged user, all the while being audited as their own user ID.
Another XAC feature is capturing keystroke input and program output. Yet another is to control access to individual commands within utilities. The latter is where this article should become interesting to XPNET users.
XAC is not intended to replace NCPCOM’s network control security, but should be used to enhance it. XAC cannot allow more access than NCPCOM allows, but can deny more access than NCPCOM. With XAC, a user who could previously stop any station, might now be limited to stop only stations whose names do not begin with P1A^POS, P1A^HOST, and P1A^STAR. Accidental or malicious attempts to stop stations whose names begin with these character strings can be denied by XAC, even though NCPCOM might otherwise allow them to be stopped.
How XAC Works
XAC acts as a pseudo-terminal. Figure 1 depicts a typical use of XAC. A user connects to the NonStop and is unknowingly given an indirect TACL session via XAC rather than a direct TACL session. XAC runs a TACL on behalf of the user. This allows XAC to “see” all input from the user and output from TACL or whatever utility or program is being executed.
XAC’s configuration files include ACACL, ACCONF, and ACCONFCO. Only the ACACL file is pertinent to this article. The ACACL is where the XAC commands are configured. The Database Server Object (DBSO) retrieves XAC commands from the ACACL file for a given XAC process to execute.
Each user accessing the NonStop in this way will have a unique XAC process that behaves just like having a TACL or similar NonStop utility in every way, except that all keystrokes can be audited; whether important or not. The beauty of this implementation is that keystrokes are audited regardless of the user ID or alias the user is logged on as. This XAC implementation may generate a significant amount of audit data.
XAC can also be implemented so that when a user connects to the NonStop, an ordinary TACL is provided. XAC is then invoked only when access to a utility as a privileged user or a restricted use command is necessary. In this XAC implementation, no direct access to privileged user IDs is allowed and users do not have aliases to privileged user IDs. Keystroke auditing occurs only when a user invokes an XAC command that is configured for keystroke auditing.
To invoke an XAC command from TACL, a user would enter “XAC” followed by a configured XAC command (e.g., XAC NCPCOM).
How XAC Can Enhance XPNET’s Network Control Security
Figure 2 is an illustration showing NCPCOM running under XAC’s control.
For XAC to run NCPCOM, the following command would need to be configured in XAC’s ACACL file.
COMMAND NCPCOM DESCRIPTION "Run NCPCOM as current user" USER GROUP,USER OBJECT $BASE24.XPNET.NCPCOM ACL $B24OPER TIMEOUT 900 OPENSBYOBJECTS \*.$*.*.*
When invoked from TACL with “XAC NCPCOM”, XAC starts NCPCOM as the current logged-on user, but could be started as any user. Only members of the $B24OPER ACLGROUP are authorized to execute this command. After 15 seconds of inactivity, this XAC session will stop. The user can run any program object that can be executed from within NCPCOM. NCPCOM security controls all access to NCPCOM commands.
While XAC can perform user verification, it is not required to do so in this case since the command will run as the current logged-on user. However, if the BASE24 Pathway NCPI server’s PARAM ENABLE-SECURITY is set to ON or DETAIL, the ACI NCPI Server process accesses its own proprietary security files to verify the operator’s credentials and command access for the XPNET node involved in the command.
To enhance NCPCOM security, an XAC NCPCOM command could be configured as follows.
COMMAND NCPCOM-ATM DESCRIPTION "Restricted NCPCOM" USER GROUP,USER OBJECT $BASE24.XPNET.NCPCOM ACL $ATMOPER TIMEOUT 900 OPENSBYOBJECTS \*.$*.*.* DENYCMD "STOP STATION P1A^POS*" DENYCMD "STOP STATION P1A^HOST*" DENYCMD "STOP STATION P1A^STAR*" ALLOWCMD "*"
This XAC command behaves just like the previous XAC command except that it denies the use of the three NCPCOM commands indicated. All other NCPCOM commands are under the scrutiny of NCPCOM’s security.
This XAC command would work fine if not for NCPCOM’s abbreviated command feature. With this feature, each element in a NCPCOM command can be abbreviated to the extent that it can be uniquely identified. This includes command keywords, object types, attributes, directives, modifiers, literals, and filters. Any abbreviation can be used as long as enough characters are entered to make the element unique. For example, STO S P1A^POS* has the same meaning as STOP STATION P1A^POS*.
To accommodate this, the XAC NCPCOM-ATM command needs to be adjusted to allow and include a regular expression. Advantage is also taken to combine the three DENYCMDs into a single DENYCMD as follows:
COMMAND NCPCOM-ATM DESCRIPTION "NCPCOM as current user" USER GROUP,USER OBJECT $BASE24.XPNET.NCPCOM ACL $ATMOPER TIMEOUT 900 OPENSBYOBJECTS \*.$*.*.* REXP_ALLOWDENY DENYCMD "STO.* S.* (P1A^POS|P1A^HOST|P1A^STAR).*" ALLOWCMD ".*"
This XAC command allows regular expressions to be used in DENYCMD/ALLOWCMD statements and now denies the operator any permutation of the indicated STOP STATION command. Prior to use, regular expressions should be tested. Figure 3 shows how a XYPRO tool can be used to build and test a regular expression.
XAC allows for greater flexibility in configuring system access. XAC offers powerful, granular access control, allowing HPE NonStop security administrators to easily configure access according to users’ roles and responsibilities so that individuals are given access to the right set of system resources. The configuration settings defined in XAC govern whether user requests to run system utilities or other programs are granted or denied. “Allow” and “Deny” features restrict commands within programs and utilities to the subcommand level, supporting segregation of duties and adhering to the Principle of Least Privilege (POLP).
Whether your organization chooses to very specifically define a job function down to individual sub-commands or fewer restrictions with complete session and keystroke audits, XAC facilitates the creation and maintenance of this secure environment without compromising employee effectiveness and efficiency.