Security Blog Shield




Bookmark and Share

Recent Posts

Selecting Network Security Protocols for z/OS Workloads

December 24, 2018

In my last blog post, we looked at the different network cryptographic protocols supported on z/OS (TLS/SSL, IPsec and SSH) and how they compare against each other. We also noted that you need to consider a much wider range of factors when selecting network security protocols for your z/OS workloads. Here are ten key questions to ask:
  1. Does your company’s security policy dictate a specific cryptographic technology or requirement? Standards can be very specific, such as “All file transfers must be protected using TLSv1.2 with at least AES-128 encryption and RSA keys of at least 2048 bits.” Or, they can be rather vague, like “All customer financial data must be encrypted end-to-end as it traverses the network.” The more specific the policy, the easier it is to select the protocol for a given workload. On the other hand, the less specific, the more latitude you have to select a protocol that might cover multiple workloads at a time.
  2. What capabilities exist on your hosts and network equipment? In order to succeed, the different security endpoints must support the same protocols, protocol versions, cryptographic algorithms and other key options that might be needed.
  3. Most companies have network-based devices like firewalls or intrusion prevention systems that do some level of network packet inspection. Will those devices still be able to perform their functions for the security protocol and version you are considering? If they cannot, is your networking staff prepared to reconfigure or compensate for the lost function?
  4. What is your communication partner willing to use? Different companies have different standards and use different infrastructure when it comes to network security protocols. For example, you might have IPsec deployed widely while your business partner has never touched it. As another example, shops that favor *IX environments may only use SSH’s SFTP for file transfer, while yours might prefer FTPS (FTP with TLS protection).
  5. Do you already have some of the relevant security infrastructure in place? For example, does your company already have a well-defined Public Key Infrastructure (PKI) in place, or are keys and digital certificates managed on a more ad-hoc basis? Do you already have TLS, IPsec or SSH deployed for other workloads or systems so that you can leverage in-house expertise?
  6. Does the network security protocol support the workload’s transport protocols? TLS works great for TCP/IP-based traffic, but you can’t use it for UDP/IP-based traffic like Enterprise Extender. IPsec, on the other hand, protects any IP-based traffic.
  7. Are the application and middleware components that comprise the workload already enabled for a specific network security protocol? You will find that many popular z/OS components are already enabled for TLS protection, either through direct use of a TLS library like System SSL or JSSE, or through z/OS Communication Server’s Application Transparent TLS (AT-TLS) feature. Some of these might even offer multiple solutions. In most cases, using the built-in support will bring benefits that other approaches may not offer.
  8. What do you want to authenticate? A specific application endpoint, like a TN3270 server, or is it enough just to authenticate the host identity? For the former, look to protocols like TLS or SSH, since IPsec (using the Internet Key Exchange protocol) performs host-to-host authentication.
  9. Do you want very specific security sessions per connection, or would you rather set up a wide-scoping session that can protect the traffic for multiple components at the same time. Since TLS is an application-to-application protocol, one TLS session tends to protect one application connection at a time, whereas a single IPsec tunnel can be defined to protect a wide range of traffic between two IP nodes.
  10. How are the different technologies implemented on the platforms involved? Does one protocol support cryptographic acceleration or other hardware features that another one does not? And remember to ask that question for each endpoint platform.
Of course, you will probably come up with other considerations as you explore your alternatives, but this list should give you a good start as you select network security protocols for your z/OS workloads.

As you proceed along the path, you will inevitably need to assess the current state of your z/OS network traffic’s cryptographic protection. Which of your workloads are already properly protected? Which are not? Where do I go to find the answers to those questions? Stay tuned for my next post to find out.

Chris Meyer is the network security architect for z/OS and an IBM senior technical staff member.
 

Posted December 24, 2018| Permalink

comments powered by Disqus