Subsystem Programmatic Interface (SPI)

The Subsystem Programmatic Interface (SPI) is the path by which management applications and subsystems exchange command-response messages and event messages.

SPI is designed to allow programmatic management of subsystem objects. An object is a logical or physical entity such as a device, a communications line, logical subdevice , process, processor, file, or transaction. Most objects are controlled by subsystems, and a subsystem itself can be treated as an object.

Normally, subsystem objects are controlled by an HP-supplied management interface that has commands to configure, control, monitor, and report the status of subsystem objects. For example, TMFCOM interfaces with NonStop TMF software to perform these functions.

For third party products and user -written utilities, the SPI interface provides a mechanism to send and receive this level of interaction to HP subsystems program- matically.

For example:

Start or stop an object (such as a Pathway terminal)

Change an object attribute value (such as the speed of a communications line)

Add a new object to the system (such as defining a logical subdevice on a communications line)

Inquire whether an object is stopped or running

AP-ADVICE-SPI-01 User-written programs and third party tools can provide mechanisms to perform both helpful and damaging commands to vital subsystems. These programs and tools must be secured in the same manner as their HP-supplied interface counterpart .

AP-ADVICE-SPI-02 User-written programs and third party tools that provide an interface to modify subsystems, such as downing a line, or bringing up a Pathway terminal should be documented as part of the Corporate Security Policy.

SPI Components

SPI messages have a common structure. Each message has a message header followed by as many tokens as are necessary to convey the relevant information.

A standard message format and protocol

A standard unit of information

The token Procedures for composing and decoding messages

Data definitions for commonly used data structures

Rules and guidelines governing message content and protocol

There are two types of SPI messages:

EMS messages

Control and inquiry messages

Caution

Tokens are self-identifying data items. A token's name usually indicates its function or the information contained in the token.

The primary SPI Subsystem components of concern to the Security staff are the contents of the Definition Files.

Definition Files

A set of files containing data declarations for items related to SPI messages and their processing. The core definitions required to use SPI are provided in a DDL file and in several language-specific definition files, one for each programming language that supports SPI. The DDL compiler generates the language-specific files from the DDL file. Subsystems that support SPI provide additional definition files containing subsystem- specific definitions.

The Definition Files typically reside in the $SYSTEM.ZSPIDEF, $SYSTEM.ZSPIEXAM and $SYSTEM.ZSPISEGF subvolumes .

SPI Standard Definitions & Libraries

The standard definitions are available for use with the SPI procedures regardless of the subsystem. There is also a set of subsystem-specific declarations for each subsystem and some sets of declarations that apply to multiple subsystems. An application using SPI needs the SPI standard definitions and also the subsystem definitions for all subsystems with which it communicates.

Securing SPI Components

BP-FILE-SPI-01 ZSPIDEF.* files should be secured "NUUU".

BP-OPSYS-OWNER-03 ZSPIDEF.* files owned by SUPER.SUPER.

BP-OPSYS-FILELLOC-03 ZSPIDEF.* files reside in $SYSTEM.ZSPIDEF

BP-FILE-SPI-02 ZSPIEXAM.* files should be secured "NUUU".

BP-OPSYS-OWNER-03 ZSPIEXAM.* files owned by SUPER.SUPER.

BP-OPSYS-FILELLOC-03 ZSPIEXAM.* files reside in $SYSTEM.ZSPIEXAM

BP-FILE-SPI-03 ZSPISEGF.* files should be secured "NUUU".

BP-OPSYS-OWNER-03 ZSPISEGF.* files owned by SUPER.SUPER.

BP-OPSYS-FILELLOC-03 ZSPISEGF.* files reside in $SYSTEM.ZSPISEGF

If available, use Safeguard software or a third party object security product to grant access to the ZSPIDEF, ZSPIEXAM, and ZSPISEGF subvolumes only to users who require access in order to perform their jobs.

BP-SAFE-SPI-01 TO 03 Add Safeguard SUBVOLUME Protection Records to grant appropriate access to the SPI subvolumes.

	Discovery Questions	Look here:
FILE-POLICY	Is there a Corporate Security Policy in regards to programmatic interface to SPI manipulation of HP subsystems?	Policy
FILE-POLICY	Is there a Corporate Security Policy to review the SPI commands used by programmatic interfaces?	Policy
OPSYS-OWNER-03	Who owns the $SYSTEM.ZSPIDEF files?	Fileinfo
OPSYS-OWNER-03	Who owns the $SYSTEM.ZSPIEXAM files?	Fileinfo
OPSYS-OWNER-03	Who owns the $SYSTEM.ZSPISEGF files?	Fileinfo
FILE-SPI-01	Are all files in the $SYSTEM.ZSPIDEF subvolume secured correctly?	Fileinfo
SAFE-SPI-01	Are all files in the $SYSTEM.ZSPIDEF subvolume secured with an equivalent Safeguard SUBVOLUME Protection Record?	Safecom
FILE-SPI-02	Are all files in the $SYSTEM.ZSPIEXAM subvolume secured correctly?	Fileinfo
SAFE-SPI-02	Are all files in the $SYSTEM.ZSPIEXAM subvolume secured with an equivalent Safeguard SUBVOLUME Protection Record?	Safecom
FILE-SPI-03	Are all files in the $SYSTEM.ZSPISEGF subvolume secured correctly?	Fileinfo
SAFE-SPI-03	Are all files in the $SYSTEM.ZSPISEGF subvolume secured with an equivalent Safeguard SUBVOLUME Protection Record?	Safecom

Related Topics

Securing Applications