SNA security
In this chapter, we provide an overview of security concepts and architecture for SNA on System z. Then, we describe some of the guiding principles for configuring SNA security.
The chapter includes the following sections:
 
General overview: See Chapter 1, “Mainframe network concepts and functions” on page 1 for a more general overview of SNA-related topics. Be sure that you are familiar with these concepts.
4.1 Introduction
In today's ever expanding business environment, securing an IT environment takes center stage in an overall business strategy. However, as the IT industry has enhanced security defenses and best practices for IP networks over the last decade, configuring secure SNA environments have not been pursued with the same zeal by some organizations.
In the past, SNA system programmers were able to rely on a hierarchical architecture, strong physical controls, and a limited amount of access to protect their critical business services. As the IT industry developed much larger networks, these assumptions no longer hold true. The introduction of new technologies that enhanced the availability of SNA with more dynamic network recovery and the use of the faster IP infrastructure, has opened the SNA networking environment. This loss of physical security, however, can be replaced by a mix of other strong security options that are integrated into the different layers of SNA.
SNA at its core was designed with the ability to wrap different layers of connections with a blanket of security. To communicate within an SNA environment you would first have to connect to a node and establish and maintain a link connection into the network. You then have to correctly negotiate a proper session and then handle the flows within the session itself. At each level, there are different security controls that can govern the connections and protect the session information.
From network border search controls, tuning options and the use of encryption ciphers, you can harden the walls of your SNA network from the inside. Even the data transactions are wrapped within several layers of connections that can contain multiple security checks.
SNA is also enhanced to take advantage of IP networking technology. To protect the transactions that flow over an IP network, you can deploy a mix of SNA and IP security. Using these controls, you can authenticate the traffic flow and protect the data from prying eyes using advanced key management and cipher algorithms.
4.2 SNA encryption versus IP encryption
Within an SNA environment, there are currently two types of transmission links that can be used. Those that run over native SNA links (XCF, AHHC, Ethernet, Token-ring) and those that tunnel over IP links (TN3270, DLSw, Enterprise Extender). IP encryption and key management techniques have advanced at a much greater pace than those within the native SNA environment. SNA encryption can still be used to secure the whole path of an LU-LU session regardless of the number of hops in between the LU partners, whereas IP security can only protect portions of the path that traverse IP. So, the question becomes: Which type of encryption should I use, SNA or IP?
SNA certainly supports encryption and authentication, and can be used to protect the entire LU-LU session path. However, everything is done using manually defined symmetric keys. The passing of the key, refreshing and distribution takes a large amount of manual effort and must be guarded from hackers.
IP security such as IPSec is limited by the length of the LU path it can protect. However, an administrator can take advantage of dynamic key distribution, refreshing, or standard cipher key protections through the use of certificates and protocols such as the Internet Key Exchange (IKE). IP security can also take advantage of AES encryption that is quickly becoming the new standard for encryption ciphers compared to SNA, which can support only up to Triple DES encryption at the time of writing this book.
Using encryption from the IP or SNA side, or a mix of both, is the choice of any organization’s risk governance on the requirements of securing their SNA data and network.
For more information about network cryptography on z/OS, see Chapter 2, “Cryptography for network security” on page 37.
4.3 Security controls using VTAM start options
VTAM has several start options relevant to security. They can be divided roughly into two areas:
4.3.1 Crypto-based start options
The start options that fall under this heading are ENCRYPTN, ENCRPREF, VERIFYCP, and SECLVLCP. The latter two, VERIFYCP and SECLVLCP, are described in 4.7, “Application security” on page 149, because they involve session partner authentication, although for CP-CP sessions. Use these options if there is a requirement to verify the authenticity of any partner CP that is currently connected to the node and the link is not an Enterprise Extender connection where the stronger IPSec authentication can be used.
ENCRYPTN determines whether VTAM supports cryptography and which cryptographic API it expects to use. ENCRYPTN should be set to ENCRYPTN=CCA in the ATCSTRXX member. This will allow VTAM to use Triple DES encryption, which is the recommended cipher suite. The value of CCA also means that, upon initialization, VTAM will attempt to detect what crypto-products are available, and decide the level of encryption that will be supported. Before the activation of the LPAR you must have installed the cryptographic hardware and had your service group define it properly on the System z hardware. Also ensure that ICSF is properly configured and active on each LPAR where encryption is to be used. As a general practice, it is best to start ICSF before any other subsystem.
ENCRPREF merely defines a prefix used for the labels of the master symmetric keys used to generate the session keys. Its default is no prefix and there is no reason to change this.
4.3.2 Access control start options
These start options establish default behavior for permitting or denying access to the system from remote SNA resources. These options can be regarded loosely as the SNA equivalent of an IP packet filter, bearing in mind the difference between connectionless IP and connection-oriented SNA. Many of these options have the characters DYN within their names. They can be overridden on individual connections by means of VTAM definitions, but the start options allow you to define the SNA equivalent of that deny all filter that protects against anything you forgot to think about.
There are seven options to be considered, roughly falling into three categories:
•APPN-related options are DYNADJCP and CDRDYN
•Subarea-related options are CDRDYN, DYNASSCP and SSCPDYN
•LEN-related options are DYNLU, ALSREQ and CPCDRSC
CDRDYN controls whether this VTAM is allowed to create dynamic CDRSCs that represent resources owned by other nodes in the network. CDRDYN can be specified as a start option or on the host CDRM definition; if the CDRDYN start option is specified, then it overrides the CDRDYN value specified on the host CDRM definition. CDRDYN is set to YES in virtually all VTAM installations because of the huge amount of work that would be involved in predefining all remote session partners as CDRSCs.
DYNADJCP (defaulting to YES) allows VTAM to define adjacent control points (CPs) dynamically. The behavior of this option can be overridden on individual link station definitions. If DYNADJCP is set to NO, each adjacent CP to which VTAM connects must be defined in an ADJCP major node. You need to balance the security requirements against the effort in coding definitions. Code DYNADJCP=NO as a start option, override it on those link stations (for example, Switched major node PU) where you are sure of the identity of the nodes that are native to VTAM, and code an ADJCP major node for any remaining valid partners.
DYNLU controls whether VTAM allows resources represented by dynamically created CDRSCs to use peripheral (type 2.1) links. If DYNLU for a link is coded to NO, either at the start option level or on the link definition, and then you must code Cross Domain Resource (CDRSCs) definitions on that host for every cross-domain resource that is allowed to use peripheral (type 2.1) links for sessions. Although this might sound like a good way to control the use of external links, this method will work only when ISR routing is used on the link. If you allow HPR, which is recommended for APPN links, the value coded for DYNLU is not an effective security control.
SSCPDYN allows VTAM to add a known partner CDRM to any adjacent SSCP table if that partner sends in a session request. DYNASSCP lets VTAM create adjacent SSCP tables dynamically. Unlike the APPN case, there is no way that VTAM will search a partner CDRM unless that CDRM has been predefined. To minimize the likelihood that one of those partners has been hacked and now contains a bad LU, set both of these start option to NO to ensure each resource is searched ONLY in the partner networks where it is expected to be found.
ALSREQ and CPCDRSC are only useful when you have LEN connections to this VTAM, which should be a rarity these days. ALSREQ (default NO) allows VTAM to accept session requests from a remote LU that has not been predefined with the correct link station name. CPCDRSC (default NO) allows VTAM to establish outbound sessions to an adjacent LEN CP that has not been predefined. Because of the lack of authentication methods for LEN resources (there are no CP-CP sessions), optimum security demands that everything is predefined (ALSREQ=YES and CPCDRSC=NO) unless there is business justification for doing otherwise.
DYNPU and Connection Networks
One other definition in this category, although not implemented as a start option, is DYNPU. DYNPU (coded as a keyword online group definitions, and usually defaulting to NO) allows a remote link station to be created dynamically without matching a switched major node PU definition. For EE connections, where most inbound switched PUs are found these days, set DYNPU as NO and predefine all connection partners.
A Connection Network is exempt from the DYNPU rules by design. However, a Connection Network cannot be used to carry CP-CP sessions, so a locate request for a session would never flow over this type of link. This requires that any node participating in the Connection Network will always have been predefined by another switched major node to its NN server and thus can be authenticated by that server. Also, due to the nature of Connection Networks, you can control the network flow using IP Security controls such as encrypted tunnels or IP packet filters.
4.4 Transport security
In this section, we describe the three most common ways that SNA communication occurs within today's enterprise IT environments.
4.4.1 Enterprise Extender
Enterprise Extender is the latest technology available to enable organizations to transport SNA traffic over an IP network. Enterprise Extender is not a product but an extension to the Advanced Peer-to-Peer Network (APPN) and High Performance Routing (HPR) protocol. Enterprise Extender technology provides an encapsulation of SNA application traffic within UDP datagrams by HPR-capable devices at the edges of an IP network. To the IP network, the SNA traffic is broken down into UDP datagrams that are transmitted through the IP backbone. To the user, it is a normal SNA session with the same Class of Service (COS) as in a traditional SNA network. By wrapping the SNA application traffic in this way, Enterprise Extender enables SNA data to be carried over an IP backbone without changing either the SNA application or the IP infrastructure.
Types of Enterprise Extender connections
There are two types of Enterprise Extender connections:
•Simple Enterprise Extender connection (static or dynamic PUs)
•Connection Network
Regardless of the type of Enterprise Extender connection defined on z/OS, each requires the creation of a VTAM External Communication Adapter (XCA) major node to identify the following essentials, at a minimum:
•UDP Ports for Enterprise Extender traffic are located at port numbers 12000-12004 in the stack and should not be changed.
•Type of Service (TOS) settings in the IP header (defaults are 20, 40, 80, C0) that are used to define the SNA Class-of-Service defined by the application as the SNA traffic crosses the IP network. The IP routed network must honor the IP TOS settings (as does the OSA Express in QDIO mode) to preserve the priority of the SNA traffic; otherwise, there is no priority.
•Logical Data Link Control Timers are timer intervals (in seconds) to determine how long to wait before considering an Enterprise Extender connection inoperative.
Simple Enterprise Extender connection
A simple Enterprise Extender connection on z/OS is defined with a VTAM switched major node using either static (predefined) PU definitions or dynamic PU definitions. When comparing the two strategies, static PU definitions are the most secure but do require more initial effort by the system programmer. Table 4-1 shows a comparison of static and dynamic PU definitions.
Table 4-1 Static versus dynamic definitions
Static (Predefined) definitions
Dynamic definitions
Individual definitions to each remote Enterprise Extender endpoint which include remote CPNAME
No individual PU definitions are required
More secure
Less Secure
Ability to specify unique naming convention for SNA resources
Limited ability to specify naming convention for SNA resources
Flexibility to define different link characteristics per remote peer
Less flexibility to define link characteristics
Ability to use TG numbering to identify remote partner
No control over TG numbering before System z V1R10
Might require large number of definitions to configure and maintain
Minimal definition
By using the static method, the system programmer can define the expected CPNAME, TG number, and link characteristics for each remote Enterprise Extender endpoint. Only those connections calling in matching those traits will be successful and thus provide some level of security. Static definition is the most common Enterprise Extender implementation method.
Although the dynamic method requires the least amount of configuration, it also provides the least amount of security to validate the remote Enterprise Extender endpoint.
Enterprise Extender Model major node
If the dynamic method is selected for defining Enterprise Extender PUs, consider deploying a model major node. A model major node provides the ability to define specific TG characteristics of the dynamic PU (such as assigning the TG number), DISCNT=NO to preserve the EE physical link after the last session terminates, and when the link fails, automatic re-dial will occur.
Also, due to the dynamic nature of the connection from the SNA perspective, it might be prudent to add some IP controls. These could be in the form of IPSec policy filters or virtual private networks (VPN) to ensure that the proper IP addresses of the incoming Enterprise Extender connections are allowed to connect to this node.
Connection Network
A Connection Network is an Enterprise Extender implementation across a shared access transport facility, or SATF, (that is, an IP network) involving a common virtual routing node (VRN) for communication. Each participant in the Connection Network defines the same VRN name. When a session request is initiated, an Enterprise Extender dynamic link is created as needed between the endpoints if they share the same SATF. The benefit an organization receives by using a Connection Network is the linear growth of definitions in a fully meshed network compared to exponential growth. In other words, Connection Network requires 2n definitions, bu tthe alternative method requires n(n-1) with n nodes.
However, this dynamic environment can be used because there are no controls on who can connect to a Virtual Routing Node. As mentioned in 4.3.2, “Access control start options” on page 133, there are several methods in both IP and SNA to control access to the host through a Connection Network. These controls are discussed in detail in the subsections that follow.
4.4.2 UDP/IP considerations
Enterprise Extender encapsulates the SNA data into UDP datagrams to route across the IP network. For each IP stack acting as an Enterprise Extender endpoint, configuring the following changes are recommended for UDP.
•Reservation of UDP ports 12000-12004 for the Enterprise Extender traffic
•Sufficient UDPRCVBUFRSIZE and UDPSENDBFRSIZE sizes (recommended to use 65535 for both)
4.4.3 Network Address Translation considerations
Network Address Translation (NAT) introduces additional complexity to an Enterprise Extender solution in that each endpoint must establish connectivity to a static IP address and therefore, only static NAT is supported. Dynamic NAT is not appropriate because an IP address needs to be determined at configuration time. If a NAT boundary is associated with an Enterprise Extender Connection Network path, hostname-based Enterprise Extender definitions are required to establish network connectivity because the EE Connection Network protocol carries IP identities within the payload.
4.4.4 Enterprise Extender IP security
Enterprise Extender allows for SNA data to be encapsulated within UDP datagrams and transferred over an IP network. As a result, Enterprise Extender traffic is exposed to the same threats as all other IP traffic. There are two methods that can be used to control the UDP/IP traffic:
•Policy Filters
•IPSec
The simplest way is by using a packet filtering firewall to only allow EE UDP datagrams in from particular IP addresses for UDP ports 12000-12004. This can be done from the router or at the host using the IPSec Policy Filters. These filters use information in the IP and UDP packet headers to either permit or deny the traffic coming into the enterprise. Usually this is deployed when an encrypted data link is already deployed; usually through a third-party ISP, to connect two organizations. Because there is no need to encrypt or authenticate the traffic coming across this link, packet filtering is sufficient. However, because the security end point is moving closer and closer to the end points of a connection, simple policy filters might no longer be sufficient.
To truly authenticate and encrypt the Enterprise Extender traffic from both endpoints, IP Security via IPSec is the recommended solution. IPSec is an industry standard protocol that provides end-to-end authentication and encryption. It is available on multiple platforms, including but not limited to, z/OS, iSeries, Linux on System z, Windows, and network routers. Using IPSec, the Enterprise Extender traffic can be protected as it flows over the unsecured part of the network or the complete EE connection path.
To enable IPSec on z/OS Communications Server, a Policy Agent daemon (PAGENT) started task must be configured with a set of policies. The IPSec policies define the IP addresses of the virtual private network (VPN) endpoints, UDP ports for application data transmission, cipher suites used for encryption and authentication, the location of the server and certificate authority (CA) certificates, and when encryption keys should be refreshed. The server and CA certificates enable the VPN endpoints to authenticate their identity and to thus negotiate a dynamic tunnel connection for encrypting the Enterprise Extender traffic. After the dynamic tunnel is established, all Enterprise Extender traffic transmitted within the VPN will be protected from unauthorized access. This is the recommended way to protect Enterprise Extender links.
4.5 TN3270 Security
This section deals with the most common type of user connection into an environment, the TN3270 connection. We explain the ways a system programmer can modify the TN3270 server to create an environment that meets their security requirements.
4.5.1 Background
The most common way to connect from workstations to SNA applications in a traditional enterprise is to use a 3270 session. This connection in the past was made via hardware devices like a 3290 through a front-end processor such as a 3745 and into the MVS host.
This type of connection, by its nature, provided a great deal of physical security because these links were protected within the infrastructure of a building. However, as time went on and the requirement for greater availability to applications grew, the TN3270 emulation was created. This is a session that runs over a TCP/IP network connection and can take the form of anything from a basic green screen to a complex set of web pages created by IBM Rational Host Application Transformation Services (HATS). Although this has done wonders in modernizing how enterprise networks can scale their business, it has also opened up security issues within an enterprise.
Because the 3270 emulation mimics the same data flows as the older hardware, it also took on many of the assumptions that the hardware did. The 3270 emulation passes many critical pieces of data in the clear, including user ID and password information. Also, this emulation at its base has no way of authenticating where the session originated from. These were reasonable assumptions, because before TN3270, all connections were hardware-based, the origins of these sessions were well known, and the transmissions from these terminals could not be easily captured. In today's environment of shared Ethernet LANs and wireless networks, the assumptions made back in the 1960's and 70's no longer holds good.
4.5.2 Securing TN3270 IP flow
It was critical that security technology be deployed within a TN3270 session flow to replace the security that was lost in this new environment. The Secure Sockets Layer (SSL) protocol was enabled within the TN3270 server to provide the ability to add encryption and authentication for a session. The SSL-enabled TN3270 server protects all data between the server and TN3270 SSL-enabled clients (or terminal emulators) such as IBM Host OnDemand and IBM Personal Communications.
4.5.3 SSL/TLS support
The SSL/TLS protocol can provide data encryption, data origin authentication, and message integrity for TCP applications in a network. This is accomplished using X.509 certificates, which can be used to trade an encrypted session key using asymmetric encryption. Figure 4-1 shows a high-level view of how SSL/TLS negotiates a session between an enabled host and client. Properly negotiated SSL sessions will, by default, authenticate the server to the connecting client. Optionally, the server can be configured to request a certificate of the client to authenticate itself to the server. Also during the handshake, security session parameters, such as cryptographic algorithms, are negotiated and session keys created. After the handshake, the data is protected during transmission with data origin authentication and optional encryption using the session keys.
Figure 4-1 Typical SSL negotiation
The cryptographic algorithms that are used for an SSL session are based on the algorithms the server and client negotiate during setup time. During the SSL handshake, the client and server exchange a list of algorithms. The algorithm selected is based on the best match between the client's list and the server's list. The selectable algorithms can be limited by configuring a subset of allowable algorithms at the server. Servers can support encryption using Triple DES or other encryption algorithms (RC2, RC4, DES, and AES). A hardware crypto coprocessor, if available, is used for DES, Triple DES, and AES encryption.
4.5.4 TN3270 SSL support
SSL/TLS support for the z/OS TN3270 server can be implemented either within the server itself, or using an AT-TLS policy with the Policy Agent, which is considered a best practice. In each case, the function is much the same but the definitions are coded differently.
Each type of SSL/TLS support provides two different forms of the SSL/TLS negotiation.
•Server-side SSL/TLS
•Client authenticated SSL/TLS
The major difference between them is whether a certificate is required to authenticate the client to the server. In most cases, the certificate distribution for client-side authentication is an administratively heavy process and the normal user ID logon for applications is enough. However, it is a really strong authentication technique and goes a long way towards satisfying security standards such as SOX, PCI DSS, or HIPPA. The server can also dictate the level of encryption and in the case that the server should not allow any encryption below the Triple DES encryption.
Currently, there are three versions of SSL/TLS negotiation:
•TLS
•SSLv3
•SSLv2
Although TLS and SSLv3 are extremely similar, the SSLv2 protocol is much older and not considered as secure. Within the server, there are controls to limit what the client can request relating to the version of SSL negotiation should be. Ensure not to allow SSLv2 negotiation by using the NOSSLV2 option.
An architectural overview of the TN3270 SSL negotiation is depicted in Figure 4-2.
Figure 4-2 TN3270 SSL negotiation
Client access controls
The TN3270 server on z/OS has extra controls to secure access across the SNA network. Using a mixture of LUNAME, IPGROUP, and PORT statements, a system administrator can control which applications a user can access. For example, if you wanted to ensure only a particular set of users can access a sensitive application, you can design your TN3270 server to allow access only to the application via a specific TCP port on the stack. You can add security to the port using the SSL/TLS support mentioned previously to ensure the confidentiality and security of the application.
4.5.5 Securing DLSw connections
Many organizations that still use SNI (FID4 connections) or boundary (peripheral) links to devices might use DLSw to communicate between organizations. Although this is a good way to communicate between two different NetIDs, SNI traffic does flow across a TCP connection. To protect the data as it traverses this link, use either IPSec VPNs or a hardware encrypted channel.
Another possible security exposure can be introduced if a DLSw router is enabled into passive mode; this type of configuration potentially allows an attacker to connect to the DLSw router as a peer. The attacker could gain access into the SNA network without having to authenticate their system to the router. Either all DLSw peers should be pre-coded or IPSec AH or ESP NULL encryption with authentication VPNs should be used to authenticate the peers at the IP level.
4.6 Searching security
Although connecting different business ventures is critical in the current business environment, it also has added significant obstacles in dealing with securing those connections. Within SNA, these obstacles involve controlling searches from going out and coming into the corporate network. In this section we describe techniques that you can use to control the searching behavior for applications within an SNA network.
4.6.1 Basics of searching
Because most SNA networks are a mix of subarea and APPN environments, it is important to understand how VTAM conducts searches. Where does a search originate from within the network? Does it come from the subarea portion of a network or does it start from an APPN node? The answer to these questions will determine how the search will be conducted and what options will come into play.
4.6.2 Subarea searches
When a search for a resource comes from a subarea environment, VTAM will use two start options to determine how the search will be conducted - SORDER and SSCPORD. The table in Figure 4-3 describes the relationship of how these two options effect the overall searching for a resource within the subarea environment.
Figure 4-3 SSCPORD & SORDER table
Although SORDER and SSCPORD control the order in which certain searches are performed, they do not, for the most part, control the contents of the search list. The contents of the search list are controlled by the adjacent SSCP tables that are defined to VTAM and by the SSCPDYN and DYNASSCP start options. For optimum security, define exactly what nodes are to be searched in the adjacent SSCP tables, and code two start options as NO to prevent VTAM adding any unwanted nodes into the search order.
In the table show in Figure 4-3, notice that if the search is started in APPN and is now being performed within the subarea environment, all of the APPN searches are ignored.
4.6.3 Searching an APPN network
If a resource needs to be discovered within an APPN environment, a locate request is sent into the network and is either answered by the owning network node of the resource by a specialized network node called a central directory server (CDS), or by a network node that is connected to another NetID, called a border node.
In 4.3.2, “Access control start options” on page 133, we explain the importance of using the DYNADJCP option in controlling which nodes will be allowed to create CPCP sessions with VTAM. However, this does not address how you control the searches within an APPN network. Consider writing a Directory Services Management Exit (DSME) for any type of APPN search that can occur in a SNA network. It is rare that one is concerned with the searching that occurs within the native environment. More important is the ability to control the searches that come in from and go out to other organizations’ networks.
4.6.4 Controlling searches of other APPN networks
When searching other networks, a special type of network node called an Extended Border Node (EBN) is used. The EBN can make connections and initiate searches into other NetIDs. In most practical applications of SNA, EBNs are used to connect different enterprises together for some shared business purpose. Ensuring that an enterprise sends appropriate searches to the correct customer networks is an important issue.
You can have a situation as depicted in Figure 4-4 where a company is connected to two different business partners.
Figure 4-4 Searching example
If searches are not sent carefully, a user within the organization could think that they are connecting to an application on a particular business’ network. However, the user is really connecting to an attacker's application that is used to gather data, such as account numbers and passwords. In this section, we explain how to prevent this and other attacks by tuning your VTAM settings.
Tuning options for searching other APPN networks
There are two APPN-specific start options that are used to control cross-network searches in an APPN network; BNDYN and BNORD. BNORD in an APPN network is similar to SSCPORD for SNI connections. Depending on what was coded, VTAM could take previous successful searches and uses this to then reorder the searching sequence. Although this option has a minimal effect when it comes to the overall security of the SNA network, it is recommended that BNORD=DEFINED is coded.
The BNDYN option has a big effect on how your searching will occur and thus must be looked at in a security context. When APPN searches for resources in different NetIDs, VTAM creates a table called an Adjacent Cluster Routing table for each NetID to control the searching. BNDYN defines how and if VTAM will add nodes dynamically to this table. There are three settings for the BNDYN option:
•When BNDYN=NONE is specified, there will not be any entries in the routing table except those explicitly coded within a predefined adjacent cluster routing list
•When BNDYN=LIMITED is specified, the Border Node automatically adds routing table entries if one of the two conditions have been met;
 – BNs and non-native network nodes that VTAM learns about, with a NetID that matches the NetID of the desired resource
 – Any node which performed a search into the network that originated from another NetID that matches the DLU’s NetID of the current search.
•When BNDYN=FULL is specified, all active border nodes in the native subnetwork and active border nodes and peripheral network nodes in non-native subnetworks attached to this node are automatically added to the routing list
Your BNDYN setting can have a dramatic effect on where your searches go. For example, having BNDYN=FULL would allow APPN searches to go to every known Border Node that is connected to the corporate NetID. Looking at Figure 4-4 on page 143 again, if the option is set to BNDYN=FULL there is a chance that NETBLACK will be searched before NETB. This could enable a session between the attacker’s CICS application and user session to allow a masquerade attack. Set BNDYN to NONE to control searching by using an ADJCLUST table, which is describe in the next section.
4.6.5 ADJCLUST tables
Use an adjacent cluster routing definition list (ADJCLUST table) to customize routing between different APPN NetIDs. When a border node cannot satisfy a search request within its own domain, it will use the ADJCLUST table to determine which cross network domains to search.
Separate adjacent cluster tables can be coded for each individual NetID that an organization is connected to (see the example in Figure 4-5 on page 145). This can include setting up searches to go through intermediate networks which allow two organizations to connect without having a direct connection. Below is a simple example of an organization that uses NETA as its NetID with a border node connected to two different NetIDs (NETB, NETC).
Figure 4-5 Basic network design
Example 4-1 is an example of an ADJCLUST table that could be coded on SYSA2.
Example 4-1 ADJCLUST table
*******************************************************************
SAMADJCL VBUILD TYPE=ADJCLUST
*******************************************************************
* DEFAULT NETWORK ID
*******************************************************************
NONET NETWORK SNVC=4, ALLOW DEPTH OF 4 NETWORKS
BNDYN=LIMITED ALLOW LIMITED DYNAMICS
ASYS2 NEXTCP CPNAME=NETA.SYSA2
BSYS2 NEXTCP CPNAME=NETB.SYSB2
CSYS2 NEXTCP CPNAME=NETC.CSYC2
*******************************************************************
* ROUTING FOR NETID=NETB
*******************************************************************
NETB NETWORK NETID=NETB,
BNDYN=LIMITED,
SNVC=4 ALLOW DEPTH OF 4 SUBNETS
BSYS2 NEXTCP CPNAME=NETB.SYSB2
*******************************************************************
* ROUTING FOR NETID=NETB
*******************************************************************
NETC NETWORK NETID=NETC,
BNDYN=LIMITED,
SNVC=4 ALLOW DEPTH OF 4 SUBNETS
CSYS2 NEXTCP CPNAME=NETC.SYSC2
In the ADJCLUST table, you can override the BNORD, BNDYN, and SNVC parameters for each NetID the APPN network is connected. For searches originating in SYSA1 without a qualified NetID, all the nodes attached to SYSA2 will be searched. This could allow a black hat to insert their SNA application into a network and have users unwittingly connect to that application in a network beyond the reach of their business.
Network-qualifying searches
Creating an Adjacent Cluster table for a Boarder Node that prevents unqualified searches from leaving the native network, carries with it a responsibility to ensure that valid searches are qualified with the correct NetID. This has the additional benefit of optimizing the search patterns. There are two ways to achieve this:
•On every node, define a CDRSC with a NetID for every cross-net target (same-net CDRSCs do not need to be defined). This ensures that all cross-net searches originating in this node carry a NetID, and thus fall under the control of the ADJCLUST table for that NetID rather than a default table. For example:
VBUILD TYPE=CDRSC
NETWORK NETID=USIBMN92
LU925 CDRSC
LU926 CDRSC
LU996 CDRSC
•On the network nodes only, define a CDRSC with a NetID and CP name. This creates an APPN directory entry. The value of NQNMODE also needs to be NAME rather than NQNAME, but this is usually so because of the default start option value which is NAME. This technique ensures that alias (unqualified) searches from served end nodes get their NetID added by the NN server before any further searching is performed, and therefore use the correct ADJCLUST table when they reach a border node. For example:
VBUILD TYPE=CDRSC
NETWORK NETID=USIBMN92
LU925 CDRSC CPNAME=EN587
LU926 CDRSC CPNAME=EN594
LU996 CDRSC CPNAME=NN556
The CPNAME value does not need to be correct, although you will save an extra search by getting them right. What matters is the creation of an APPN directory entry, because that is the first place the NN server looks when it receives a search request from a served end node. If the coded values are not correct, the search will fail, but the subsequent broadcast will succeed and will update the values in the directory entry.
Which of these two methods you use depends on your network topology and the relative amounts of effort needed to implement each. The first method works for searches originating from this node or received over a subarea connection. The second method works for all searches, including those received over APPN.
4.6.6 Controlling searches entering a network
Although controlling searches originating in your network is important, it is even more important to control searches destined to your network. Each enterprise needs to protect their network from unwanted searches. In the past, this was manually done using one of two exits (SME or DSME) to control the searching. However, in recent releases of z/OS, some of the functions in these exits have been incorporated into z/OS Communications Server.
4.6.7 Session Management Exit
The Session Management Exit (SME) is a multifunction exit routine you can use to control and manage LU-LU session-related functions. You can use the exit to authorize session establishments, obtain session accounting data, and better manage SSCP and GWPATH selection. In addition, VTAM can invoke the SME exit for the following functions:
•For each session establishment before any cross-domain flows
•For each session establishment after the destination resource for the session has been determined
•To determine ordering for the adjacent SSCP tables to try for each cross-network session establishment
•To translate the name, determine the owning SSCP, or translate CoS and logo mode (some of these functions are for cross-domain session establishments, others are for cross-network session establishments)
•To determine the appropriate ALS to use as the connection for an independent LU that is the destination LU (DLU) for the session
•To modify the virtual routes (VRs) and the associated transmission priorities (TPs) that are to be used in session establishment or RTP pipe setup
This exit will be called only during subarea-side function where the session awareness is maintained and only when a session between the OLU and DLU will take place. VTAM can invoke the session management exit at certain points in processing such as:
•When VTAM initialization has completed
•When normal VTAM termination occurs
•During XRF session switch
•SSCP takeover
•MNPS recovery
4.6.8 Directory Services Management Exit
The Directory Services Management Exit (DSME) is similar to the SME exit. It is used to authenticate and control APPN searches, whereas the SME exit is used for Subarea searches. It has many of the same base functions that the SME exit has, but for APPN searches, instead. For example:
•Initial Authorization for an LU search
•Border Node Selection
•Re-drive of Authorizations for LU-LU search
The DSME exit can also control which session searches are allowed, depending on the following criteria, among many others:
•OLU name or NetID
•Whether the search is fully qualified or not
•The adjacent CP name or NetID in the OLU direction of the node performing the search
4.6.9 Searches that are not network-qualified
Use the Adjacent control point (ADJCP) major node to control how adjacent CPs can connect to this VTAM. One of the parameters is the ALIASRCH key word. This controls whether an adjacent node from another NetID is allowed to send not fully qualified locates into a border node on your network. If ALIASRCH is set to NO, the adjacent node will not be allowed to send non-qualified searches into the enterprise network. This requires you to create an ADJCP table entry for each of the cross-network connections. However, as a general rule, it can be useful as an aid to keep track of the nodes the enterprise should be connected to.
4.6.10 Authorized Cross-Net searches
The AUTHNET option on the adjacent control point table allows you to limit what NetIDs can be searched through your network.
You must add only the AUTHNET parameter to an ADJCP definition with a list of NetIDs that can be searched for by the adjacent node being defined. This would block the ability of a black hat to use an intermediate network to perform any searches into another network unless they are explicitly allowed. For example:
In Figure 4-6 on page 149, there are three networks connected to NETX for one reason or another. NETBLACK has a hacker that is attempting to access NETA or NETC resources even though there is no reason that a search should be allowed through NETX to either of these networks.
On NETX.SYSX1, the following ADJCP list has been predefined:
*******************************************************
SAMADJCP VBUILD TYPE=ADJCP
*******************************************************
* Allow NETA to search NETC C *
*******************************************************
SYSA2 ADJCP NETID=NETA,NN=YES,AUTHNETS=(NETC) X
ALIASRHC=NO
*******************************************************
* Allow NETC to search NETC A *
*******************************************************
SYSC2 ADJCP NETID=NETC,NN=YES,AUTHNETS=(NETA), X
ALIASRHC=NO
*******************************************************
* Do not allow NETBLACK to search any networks *
*******************************************************
SYSB2 ADJCP NETID=NETBLACK,NN=YES,AUTHNETS= X
ALIASRHC=NO
Figure 4-6 Example of Authnets
This ADJCP table prevents any search requests coming from NETBLACK but allows NETA and NETC to perform searches on each other.
4.7 Application security
SNA provides the same basic security functions as IP does, namely data confidentiality, data integrity and partner authentication. The major difference is that SNA has no asymmetric encryption, so the following conditions apply:
•Key distribution and key management must be done manually
•All partner authentications must be done via the possession of shared symmetric keys
Data confidentiality and data integrity work in similar fashion whether the session concerned is dependent LU (z/OS to z/OS) or independent LU 6.2 (where one partner does not need to be owned by z/OS). The same is true whether the API used is the record API or the APPCCMD API. Authentication is somewhat different in the LU 6.2 environment, where VTAM provides extra facilities for applications using the APPCCMD API.
4.7.1 Session-level encryption for data confidentiality
The shared symmetric key used in data encryption is exchanged securely between partners during the session setup flow. This typical example is the most complex case, namely an SLU-initiated dependent LU session:
•The administrator installs shared symmetric keys (only DES and Triple DES are supported) on each partner node. These are the master keys that are used to encrypt the session keys, and there should be one key per physical node. Each VTAM node will have installed:
 – Its own key
 – The keys for all partner VTAMs and independent LUs with which it is expected to communicate securely
 – The keys for all of the dependent LUs it serves that are capable of SNA encryption
•The VTAM definitions determine whether encryption is to be performed on a particular session. If it is, the SLU VTAM performs the following functions:
 – It generates a symmetric key for use in the session.
 – It encrypts this key by using one of the master keys installed by the administrator twice: Once using the key for the SLU node and once using the key for the partner VTAM node
 – It sends both the encrypted keys to the PLU VTAM in the CDINIT or locate request.
 – PLU VTAM then decrypts its copy of the session key but sends the other copy with the BIND to the SLU
 – The SLU device decrypts the session key in the BIND so that now both partners have the same key (the session data now flows in encrypted form).
This is the way it works within an up-to-date APPN network if you have installed the appropriate keys (for the SLU node and for the PLU's CP) in the SLU VTAM’s key database. The locate or CDINIT requests flow end-to-end without any encryption or decryption on the session path, even if there are subarea hops on the path.
If the partner’s key cannot be found, or if VTAM is a subarea node, the session key in the CDINIT must be decrypted at each intermediate node, and re-encrypted using the master key of the next node on the path. Thus, the adjacent node’s key is required to be in the SLU VTAM’s key database rather than the partner node's key.
Even if the network topology permits end-to-end crypto session setup, an alternative is to let the NN servers of the session endpoints take part in the process. The setup flows are then in three parts, with encryption and decryption being done at each NNS and at each endpoint.
The network configuration determines which session initiation method (end-to-end, host-by-host, or NNS-to-NNS) is used, based on the complexity of the network and the effort required to set up the key databases. End-to-end means less overhead in setting up the session but more key administration. Using host-by-host means more work in setting up the session but fewer keys defined in each host. Letting one or both NN servers take part is a compromise between these two options.
Whether the session initiation is done end-to-end or host-by-host, the actual session data always flows encrypted end to end. The whole idea of the initiation flows is to send the session key securely from SLU to PLU.
This scheme works for both record API and APPCCMD API. With LU 6.2, the actual encryption options are negotiated on the BIND and BIND response.
Setup of session-level encryption (SLE)
By default, VTAM supports SNA session encryption, but you can turn it off, or restrict the cryptographic products to be used, using the ENCRYPTN start option.
As to the session itself, the definitions that determine whether encryption is used are coded in the following places:
•The APPL definition of the PLU
•The APPL or LU definition of the SLU
•The mode table associated with the SLU
The APPL definition has two relevant keywords: ENCR and ENCRTYPE. ENCRTYPE is easy as the options are DES or TDES24 (triple DES). VTAM uses the higher of the SLU's and PLU's values. Triple DES is preferable because DES is no longer considered a secure cipher.
ENCR can have the following values:
COND Try to secure every session, but set up a clear session if the negotiation fails.
REQD Sessions must be encrypted. Session setup fails if the negotiation fails.
OPT We don’t care, so let the partner decide whether sessions will be secured or not.
NONE There will be no encrypted sessions with this application.
SEL The application will specify (using an appropriate API) which messages are to be encrypted. As with REQD, if the crypto negotiation fails then the session setup fails.
The LU definition has the same values and the same meaning for ENCR and ENCRTYPE, except that the SEL value is meaningless and thus not available. In addition, the LU definition has a CKEYNAME keyword that points to the master key associated with this LU. An application acting as SLU always uses its node's master key. The key database must have a suitable key filed in it under that name. The default for CKEYNAME is the LU name.
Use the mode entry associated with the SLU to override the values in the VTAM definitions. However, security cannot be decreased. For example, if the VTAM definition says Triple DES then you cannot override that with DES in the mode entry.
These are the keywords in the mode entry:
•ENCR defines a bit string that corresponds to the ENCR value in the LU or APPL definition.
•ENCRTYP has only one valid value, namely TDES24. Omitting ENCRTYP defaults to DES.
•CKEY allows you to use an alternate key name for this session. You can define alternate (master) keys for temporary use while the primary master key is being updated.
Installing keys
All of the previous setup tasks are business as usual for a VTAM systems programmer. What might be unfamiliar is the process of installing those master keys on the VTAM nodes.
If triple DES is to be used (the only serious option), a product implementing the CCA (Common Cryptographic Architecture), such as ICSF, must be installed. VTAM issues ICSF calls to generate, encrypt, and decrypt the session keys.
ICSF generates the master keys for you. The local copies of the keys (both for this node and for partners) are stored in the secure key database. At the same time, clear keys are produced for export. Thus, you can generate keys for all nodes on the same VTAM and simply export the clear versions to the desired places, where they too will be placed in the secure database.
4.7.2 Message authentication for data integrity
SNA message authentication works in almost exactly the same way as data confidentiality (encryption), except that rather than encrypting the message itself, it encrypts a hash value (message authentication code) appended to the message. The same algorithms (DES or triple DES) are available, and the same methods are used to generate the keys.
In fact, VTAM’s message authentication offers an alternative to crypto techniques, namely a message digest created by an internal VTAM algorithm, rather than DES or triple DES. This alternative cannot be regarded as truly secure.
To invoke message authentication for a session or sessions, we again have additional keywords on the APPL definition (not LU definition) and the mode entry. On the APPL definition, the following meanings apply:
MAC Specifies whether message authentication is required (MAC=REQD), preferred (MAC=COND) or not supported (MAC=NONE).
MACTYPE The method of producing the message digest: MACTYPE=CRC (VTAM’s home made code) or MACTYPE=DES (the real thing). If MACTYPE=DES, the value of ENCRTYPE determines whether DES or triple DES is actually used.
MACLNTH The length of the message digest, with 4, 6, or 8 as the valid values for DES. The longer, the better.
On the mode entry at the SLU end, exactly the same keywords are used to override the MAC specifications for a given session.
4.7.3 LU 6.2 session-level authentication
In addition to the encryption and data integrity features already described, LU 6.2 resources have an extra authentication feature available for them. The partner LUs authenticate with each other by exchanging encrypted random data on the BIND and BIND-response. The encryption is done using DES (not triple DES) under a shared symmetric key.
The key itself (referred to as a password in the VTAM literature) is held in RACF, and you need to define the appropriate RACF profiles in the APPCLU resource class to hold the passwords. A password is required for each LU-LU pair that will engage in session level authentication.
Because APPN control points are LU 6.2 resources, the same principles apply to CP-CP sessions as for any other LU-LU sessions. This is a particularly useful feature when you need to be sure that nobody has introduced a rogue APPN node into your network, which is much easier to do in these days of ubiquitous EE.
Configuring LU 6.2 authentication
To protect a VTAM application program against an impostor partner, you need to:
•Choose an application program that uses the VTAM APPC API, not the record API. Applications that use the record API must code the authentication algorithms. CICS is the major LU 6.2 user of the record API.
•Code the VERIFY and SECLVL keywords as appropriate on the APPL definition, whether SLU or PLU or both. APPC=YES is a prerequisite.
•Code the appropriate RACF resource profiles
The VERIFY keyword determines whether authentication is required (VERIFY=REQUIRED), optional (VERIFY=OPTIONAL), or not supported (VERIFY=NONE).
Use SECLVL to indicate either the basic or the enhanced level of authentication is to be used. The choices are LEVEL1 (basic), LEVEL2 (enhanced) or ADAPT (pick the higher one of the two partners’ choices). The difference between the basic and enhanced algorithm is that the enhanced algorithm sends an encrypted amalgam of three values (two random numbers and the SLU name) rather than just one random number.
If the sessions to be protected are CP-CP sessions, there are no APPL definitions. The VERIFYCP and SECLVLCP start options do the job of the VERIFY and the SECLVL keywords, respectively.
The name of the RACF profile depends on two factors:
•Whether this profile is for CP-CP sessions
•Whether the local LU supports network-qualified names (the ACB has NQNAMES=YES).
In this case, the name of the profile must be in this form:
localNetID.localLUname.remoteNetID.remoteLUname
If neither of those conditions is true, the profile has only three parts:
localNetID.localLUname.remoteLUname
Therefore, you would code these RACF definitions:
RDEFINE APPLCU NETX.VTAM1.NETY.VTAM2 UACC(NONE) +
SESSION(SESSKEY(X'8B44D208C1AA'))
Notice the use of the SESSION optional segment to define the DES key that is used in the authentication. The same key must be installed in the partner node.
Do not forget SETROPTS CLASSACT(APPCLU) to activate the class.
4.7.4 LU 6.2 conversation-level authentication
Session-level authentication is designed to verify the identity of a partner LU before an LU 6.2 session starts. However, an LU 6.2 session typically carries many conversations, each of which might represent a different individual user. Conversation-level security is designed to authenticate the user on any given conversation.
Conversation-level security is completely under the control of the LU 6.2 application. If the application uses the record API, VTAM has no involvement in the process. If the application uses the APPCCMD API, the SECACPT keyword of the APPL definition can be used:
•SECACPT=NONE means that conversation level security is not supported.
•SECACPT=CONV means that conversation level security is supported.
•SECACPT=ALREADYV means that the already verified option of conversation level security is allowed in addition to the CONV level. This is used when an application program passes an incoming request on to another program. The first program has already verified the user ID and password, so it tells the second program not to bother.
•SECACPT=PERSISTV means that the persistent verification option is supported. This allows two application programs to have multiple conversations with each other, but performs the verification only once.
•SECACPT=AVPV means that both ALREADYV and PERSISTV are supported.
Because conversation-level security implements a user ID and password, it is not to be regarded as secure unless the session is encrypted.
4.8 Recap of recommendations
This section summarizes the high-level practice recommendations to use for SNA network security.
•Policy recommendations:
 – Do not allow mixed security environments (for example, production and test) to be connected via SNA.
 – Be sure to separate system programmer and system operation duties between two or more individuals.
 – Allow only as much access to any resources as is required to perform tasks.
 – Ensure that all resource definitions are purged when equipment is removed from an SNA environment.
•Network recommendations:
 – Secure SNA links using IP with some type of encryption and authentication (IPSec VPNs or SSL/TLS):
 • For Enterprise Extender, use IPSec to protect the data.
 • For TN3270, use AT-TLS or SSL/TLS to protect the data.
 – Review the TN3270 settings that can control access to VTAM applications
 – Evaluate the use of multiple TN3270 servers to separate those applications that hold sensitive data from those that do not.
 – Do not allow nonqualified searches to enter the SNA environment from other NetIDs.
 – Set BNDYN=NONE and use ADJCLUST tables to secure network searches.
•Platform recommendations:
 – Set up protections for VTAM data sets by using RACF or an equivalent SAF interface product.
 – Code adjacent CP table definitions for any non-native nodes to restrict access.
 – Code adjacent SSCP tables to control searching.
 – Modify DYNADJCP, DYNASSCP, and SSCPDYN start options to NO.
 – Code ALIASRCH to NO and use the AUTHNET option in the ADJCP definitions for cross-network connections.
•Application:
 – Evaluate the use of session-level encryption and authentication techniques to secure sessions that carry critical data.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset