|Issue 3, 2011||Download pdf|
EntireX Security is a set of built-in features that provide authorization, authentication and encryption to an EntireX platform, supporting end-node and network security topologies. These features are valuable for distinguishing usage, controlling access, and protecting private messages. Knowing how to fully leverage EntireX Security will assert full-time protection of corporate assets and customer identity—one transaction at a time.
This Article Assumes:
The ingredients used to create and deploy a secure environment for processing critical information can only be as good as the governing policy, risk assessment, and scope for prevention, detection, response, self-testing, etc. required for important business processes. The choice of security
services, techniques, and methods should be entirely based on the premise of these management or organizational directives.
EntireX provides a set of turn-key services and access methods in which roles—identity authentication, resource authorization, and message encryption—all play an important part in securing access to critical user information and corporate assets without writing code.The following information is designed to provide knowledge about these important security functions and how EntireX incorporates each of these roles to allow users to make informed security decisions with regards to their over-arching security governance and policy directives.
Let’s review how a message is transported and processed through a typical EntireX client/broker/server topology. Assume a client is requesting information through an EntireX Broker that results in a mainframe server transaction being invoked and a response sent back to the client, as shown in Figure 1.
This flow of information forms the premise of a business process potentially containing private (hazardous?) information that may need to be handled securely across virtual application components (blue) and shared network transports (green).
Authentication: The Process of Identifying Usage from Start to Finish
Are you really who you say you are? The validation of the identity of a user whether a person, entry point, or some other application entity, is the role of the authentication security service. Although authentication starts at the beginning of a user session, it is also imperative to maintain authentication throughout the duration of a connection due to potential malicious activities.
EntireX authentication is designed for application components executing on different platforms to be validated against the security repository where the broker kernel resides (e.g. RACF on z/OS). It is the
responsibility of the client application (user) to supply the userid and password on the first call (e.g. the logon for an RPC message). After this, the broker recognizes the identity of the user on subsequent occasions through a combination of userid and endpoint identification (or userid and token where supplied). The broker verifies the completeness of the unique security token passed on all subsequent calls and, if this is not as expected, the broker automatically closes the session and the application (user) is expected to challenge identity and re-establish a new session.
Endpoint identity can be based on IP address, machine name, certificate, or even biometrics. It is used to determine a physical userid passed to the broker and subsequent unique token used to
validate each message. SSL also provides endpoint authentication using certificates at the transport level (more below).
Using SSL and the newer Transport Level Security (TLS) assures that sessions are not hi-jacked in the middle of a user interaction and that payload data is cryptographically secured. Keeping
maintenance levels of the EntireX and security components (such as SSL/TLS) current will assure the latest cryptographic techniques are used against security attacks.
An application identifying itself by the combination of userid and token can continue running the same broker session, even when the physical connection is passed to another thread or program
within your application, provided it maintains the value of the initial token in the broker control block. This token-based authentication is recommended for multithreading applications or applications executing within a Web server.
In order to use SSL as the secure transport method for EntireX, you need to have certificates available at various locations and for various purposes. EntireX ships with a certificate example file containing private/public keys and signature algorithm designed for testing the security infrastructure interoperability with your applications. Once you have tested this example certificate in your Certificate Authority (CA) domain, you will need to replace this example certificate (client and server) with your own under the guidance of your security office.
Authorization: The Process of Contro lling Access to Resources
Role-based authorization determines whether or not client and server application components are allowed to read, update, or delete specific digital assets managed by the platform system. There are numerous access control services that are used to determine what resources a user may view or manipulate.
- IP filtering rules can be defined in the z/OS TCP stack or within the EntireX Server to Broker configuration. This capability is used to define two devices that are allowed to communicate with one another, which TCP/IP protocol will be used, the ports to be used, etc. (which could also be used as an alternative for authenticating broker access for clients and servers at the physical IP level).
- Access Control Lists (ACL) are used by the SAF interface and repository (such as RACF) to enable the administrator or mainframe owner to build a list describing the users or other system entities granted access and the level of access granted for a specified resource. Within the access list, individual IDs or services (CLASS/SERVER/SERVICE) can be granted a distinctive authority such as read, write, update, execute for specific users/groups.
Encryption: The Process of Assuring Message Privacy
SSL and the TLS standards (used interchangeably in this document) protect data transmitted through applications such as FTP, HTTP, Telnet, etc. by using selected algorithms matching the cipher suites contained in both client and server certificates.
Critical to SSL, certificates can be described as electronic passports. They contain information about someone (or a device or location), generally called the Subject. The authenticity of the subject’s information is digitally signed by a trustworthy instance, called the Issuer. With certificates, this issuer is also known as a Certificate Authority.
Confidential messaging ensures that data is read only by those who should be reading it. It goes beyond access control and restricts viewing of data over a wire (in the case of communication sniffers used to read data packet information). This security service can use physical security, encryption (based on selected algorithms), data masking (passwords), and security protocols such as SSL/TLS, IPSec, etc. to scramble data.
In EntireX Security, a client application can create and encrypt a message before sending it via a broker to a server application or vice versa. The setting of encryption by a client application activates encryption between that client application and the broker kernel; it is independent of the encryption between the broker and the server application. However, the behavior of encryption from the client via the broker to the server is controlled by the broker attribute ENCRYPTION-LEVEL or at run-time through programming a control block parameter of the same name.
The preferred way of message encryption is using SSL which is leveraged in EntireX Security. The mainframe platform offers unique built-in keystore and keyfile capabilities along with handling the certificate authority duties through the RACF repository. Please see additional information for managing certificates at the communities’ link below.
Configuring EntireX Security
It is easy to picture EntireX Security as a big toggle switch orchestrated from the Broker with a simple On and Off. This ‘switch’ is located in the Broker Attributes file under the DEFAULTS=BROKER through the following record (note: simply remove the comment asterisk):
SECURITY = YES
This will then enable the security details section of the attributes file. Additional details can be found in my WIKI article “EntireX Security Feature – What it is, How it works”
|Important: It is the location of the broker kernel that determines the point at which authentication and authorization checks are performed. Encryption and decryption are best performed using SSL.|
Figure 2 highlights EntireX Security and depicts the network topology of Broker and Client/Server environments respectively.
Universal access requires universal security. As soon as application access and devices become more connected over a widespread network such as an intranet or the Internet, protecting the new paths to new processes can become a costly liability without proper security.
Every day, there are new devices sprouting up and new security threats—both inside and outside the rganization—to deal with. Provisioning a security layer across the gamut of access points and applications based on usage roles that meet or exceed the organization’s policies is one of the fundamental advantages for EntireX users.
EntireX achieves universal security by using standard security interfaces (such as SSL) across all of its connectivity, platforms, and access layers while enabling diverse business processes—one transaction at a time.
Visit the Software AG Tech Community to learn more about “EntireX Security Feature – What it is, How it works”