What does security mean for CICS?

Who do you trust?

Security is based on trust. CICS Transaction Server supports different levels of security, depending on your connectivity and the trust associated with it. The lower your trust, the higher the level of security that you need.

If CICS is directly connected to systems outside your enterprise, you need a higher level of security. If CICS connects only to trusted systems inside your enterprise and the users of the applications are trusted (for example, they are all employees of your enterprise), a medium level of security can be used. If CICS is isolated and can be reached only by trusted systems and trusted users, a lower level of security can be used.

If you are operating a Zero Trust strategy, then your aim is a principle of never trust, always verify. In this case access is minimized to only what users' need for their role, and access checks made on all resources that a user accesses. This checking is independent of whether a request to CICS originates inside or outside of the enterprise.

Security principles

Software security follows some fundamental guiding principles. Here's how CICS supports those principles:

Identification

Identification is the ability to assign an identity to the entity that is attempting to access the system. Typically, the identity is used to control access to resources and to audit requests. Depending on the authentication model, the identity might come from the authentication credentials or it might be asserted from another server.

CICS is designed to work with user IDs that are stored in the z/OS security registry. It can also work with non-z/OS user IDs, such as an X.500 ID, and these non-z/OS user IDs are known as distributed IDs. For authorization purposes, distributed IDs can be mapped to a z/OS user ID on entry to CICS. The distributed ID might also flow alongside the z/OS user ID so that it is available to the application and can be used for auditing.

User registries store user account information so that it can be accessed during authentication and authorization. RACF is the primary z/OS user registry, which is accessed through the SAF interface. Some other types of user registry can also be used with CICS, for example, if you use CICS Liberty, LDAP.

See How it works: Identification in CICS and User registries for more information.

Authentication

Authentication is the process of validating the identity that is claimed by the accessing entity: is this entity who it claims to be? Authentication is done by verifying authentication information that is provided with the claimed identity. The authentication information is generally referred to as the accessor's credentials. Authentication is usually the first step in security processing. After it is authenticated, an identity can be asserted to the downstream security processing, meaning that these steps trust that the identity was successfully authenticated by the upstream steps.

In CICS, authentication can be omitted if the asserted identity comes from a trusted system that already authenticated the user.

CICS Transaction Server supports the following types of authentication:

• Basic authentication, which uses credentials in the form of a password or passphrase. The passwords or passphrase are verified by the user registry. A special version of a basic authentication token is a PassTicket, which is a time-limited, one-time-use password for a specific system.
• Multi-factor authentication, which requires the user to provide multiple pieces of information: something you know, something you have, and something you are. This information is provided in the form of a Multi Factor Authentication (MFA) token. They can generally be used in the same interfaces in CICS as passwords and passphrases.
• Client certificate authentication, which requires the user to provide a digital certificate that is then mapped to a user ID. The certificate must be issued by a trusted third party or certificate authority.
• Third-party authentication, where the client authenticates with a third-party authentication server. This server generates an authentication token such as a JSON Web Token (JWT), Security Assertion Markup Language (SAML) token, or a Kerberos token. The authentication token is then used to authenticate with CICS.

See How it works: Authentication in CICS for more information.

Authorization

Authorization is the process of checking whether an identity that is already authenticated should be given access to the resource that it is requesting. A typical implementation of authorization is to pass a security context that contains the identity that was authenticated, to the access control mechanism.

CICS Transaction Server supports different types of authorization to:

• Run CICS transactions (transaction security)
• Access resources (resource security)
• Use of CICS system programming commands (command security)
• Communicate between CICS systems (intercommunication security)
• Control access to a resource in an application served by Liberty (role authorization).

See How it works: Authorization in CICS for more information.

Integrity

Integrity ensures that information was not altered in an unintended way during transmission or storage. When data is transmitted over a network, integrity checks that the received data is the same as the data that was sent.

CICS Transaction Server uses security protocols, such as SSL or, more recently, TLS, AT-TLS, or JSSE, and message-based security to provide data integrity for the transmission of data. See How it works: Confidentiality and integrity in CICS for more information.

Confidentiality

Confidentiality, or privacy ensures that an unauthorized party cannot obtain access to data. Typically, confidentiality is achieved by encrypting the data, for example, by using TLS or WS-Security.

See How it works: Confidentiality and integrity in CICS for more information.

Auditing

Auditing is a key part of a security infrastructure. It involves the validation of security-related events, such as the sign-on of a user, to ensure that security standards were correctly applied to the processing of requests.

See How it works: Auditing in CICS for more information.

Nonrepudiation

Nonrepudiation means that a data sender and a data receiver are able to provide proof to a third party that the sender sent the information, and the receiver received the identical information. Neither side can then deny that it happened.

Security facilities available in CICS

Figure 1 summarizes the options that are available in CICS Transaction Server. If Liberty is installed with CICS to run as an application server in a JVM server, more facilities become relevant and these facilities are shown in purple in the diagram.

What CICS security doesn't cover